Nice changes by @madaidan:
SUID Disabler and Permission Hardener: Difference between revisions - Whonix
Inspired me to improve a bit more:
SUID Disabler and Permission Hardener: Difference between revisions - Whonix
Great idea!
dpkg-statoverride
does not support that yet. feature request: dpkg-statoverride: support for capabilities
Meaning there might be no standard way in which packages implement setting capabilities yet. Therefore I wanted to look at a package that sets capabilities. For example package iputils-ping
contains capability enabled binary ping
. From the package postinst script:
/var/lib/dpkg/info/iputils-ping.postinst
#!/bin/sh
set -e
if [ "$1" = configure ]; then
# If we have setcap is installed, try setting cap_net_raw+ep,
# which allows us to install our binaries without the setuid
# bit.
if command -v setcap > /dev/null; then
if setcap cap_net_raw+ep /bin/ping; then
chmod u-s /bin/ping
else
echo "Setcap failed on /bin/ping, falling back to setuid" >&2
chmod u+s /bin/ping
fi
else
echo "Setcap is not installed, falling back to setuid" >&2
chmod u+s /bin/ping
fi
fi
exit 0
# Local variables:
# mode: shell-script
# tab-width: 4
# indent-tabs-mode: nil
# end:
dpkg -S /sbin/setcap
libcap2-bin: /sbin/setcap
cat debian/control | grep cap
Recommends: libcap2-bin
So if libcap2-bin
does not get installed early enough (before iputils-ping
) is installed, the Debian maintainer script will set SUID instead of using capabilities. Assuming that other packages might be implemented in a similar way, we should find a way to make sure package libcap2-bin
is installed during the build process as early as possible.
Other random examples having a similar use of setcap
:
grep -rl setcap /var/lib/dpkg/info
/var/lib/dpkg/info/iproute2.config
/var/lib/dpkg/info/iproute2.postinst
/var/lib/dpkg/info/libcap2-bin.md5sums
/var/lib/dpkg/info/libcap2-bin.list
/var/lib/dpkg/info/libgstreamer1.0-0:amd64.postinst
/var/lib/dpkg/info/gnome-keyring.postinst
/var/lib/dpkg/info/wireshark-common.postinst
/var/lib/dpkg/info/wireshark-common.templates
/var/lib/dpkg/info/iproute2.templates
/var/lib/dpkg/info/kinit.postinst
/var/lib/dpkg/info/iputils-ping.postinst
Meanwhile for packages by Whonix or Kicksecure we can just add Depends: libcap2-bin
in debian/control and run setcap
during postinst.
Happy to work towards a completely SUID / SGID free by default system. Worthwhile development goal to even get rid of Whonix / Kicksecure requiring sudo
/ any /etc/sudoers.d
exceptions?
Would be specifically interesting in context of:
Multiple Boot Modes for Better Security: an Implementation of Untrusted Root
Persistent User / Live user / Persistent Secureadmin / Persistent Superadmin / Persistent Recovery Mode
Now this list of sudoers exceptions needs to be ported to capabilities.
./sdwdate/etc/sudoers.d/sdwdate
./dist-base-files/etc/sudoers.d/30_default-password-lecture
./anon-gw-anonymizer-config/etc/sudoers.d/anonymizer-config-gateway
./tor-control-panel/etc/sudoers.d/tor-control-panel
./tor-control-panel/etc/sudoers.d/restart-tor-gui
./uwt/etc/sudoers.d/uwt
./security-misc/etc/sudoers.d/xfce-security-misc
./security-misc/etc/sudoers.d/security-misc
./security-misc/etc/sudoers.d/pkexec-security-misc
./tb-updater/etc/sudoers.d/tpo-downloader
./whonix-setup-wizard/etc/sudoers.d/whonix-setup-wizard
./usability-misc/etc/sudoers.d/tunnel_unpriv
./usability-misc/etc/sudoers.d/sudo-lecture-disable
./usability-misc/etc/sudoers.d/pwfeedback
./usability-misc/etc/sudoers.d/user-passwordless
./usability-misc/etc/sudoers.d/upgrade-passwordless
./live-config-dist/etc/sudoers.d/live-config-dist
./qubes-whonix/etc/sudoers.d/qubes-whonix
./whonixsetup/etc/sudoers.d/whonixsetup
./sdwdate-gui/etc/sudoers.d/sdwdate-gui
./whonix-xfce-desktop-config/etc/sudoers.d/whonix-xfce-desktop-config
./vm-config-dist/etc/sudoers.d/power-savings-disable-in-vms
./whonixcheck/etc/sudoers.d/whonixcheck
./msgcollector/etc/sudoers.d/msgcollector
./tb-starter/etc/sudoers.d/tb-starter
Help welcome!
Would we need a wrapper around setcap
? Because https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502580 mentions several conditions under which setcap
can fail.
- Take into account systems no supporting fcaps, this includes:
- (for now) non-Linux systems,
- Linux w/ old kernels or kernels w/o fcap compiled in,
- file systems not supporting fcaps, and/or w/o mount time enabled
xattr.
Or don’t care much about this and just ignore errors using setcap [...] || true
?
Unlikely. We could cover
/root
since that’s a bit more likely to contain suid binaries and it wouldn’t increase scan time much since most users would be storing their files in an unprivileged user’s home directory.
Added to wiki:
- It does not search folders
/root
because no SUID binaries should be there by default. That folder is by default readable only byroot
. Ifroot
was to create a custom SUID and move it there, thenroot
should be able to execute it.
That would break a lot of things. For example, if I mounted a drive containing another Linux system to
/mnt
in order to debug an issue, permission hardener would kill all suid binaries in it and become extremely slow. A better solution would be mounting those filesystems with thenosuid
option since it’s much easier to revert (mount -o remount,suid /mnt
vs. resetting all file permissions).
Good point. Now mentioned in wiki.