[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Disable SUID Binaries

https://github.com/QubesOS/qubes-issues/issues/2695 has interesting ideas.

Quote Solar Designer (someone that Joanna Rutkowska respects):

Ideally, there should be no SUID binaries reachable from the user account, as otherwise significant extra attack surface inside the VM is exposed (dynamic linker, libc startup, portions of Linux kernel including ELF loader, etc.)

No idea yet.

Related:
walled garden, firewall whitelisting, application whitelisting, sudo lockdown, superuser mode, protected mode

2 Likes

To remove all SUID bits from binaries, we can run

chmod u-s -R / && chmod g-s -R /

This will break some binaries though. For example, ping needs to be setuid to open a socket.

These can be fixed by only giving them the needed capabilities with the setcap command. For example, we can give ping just the CAP_NET_RAW capability without having to give it full root access.

1 Like

Looks like a sledge hammer approach. I mean, implementations that are ok as a sysadmin for its own computer are not necessarily advisable to be applied by default in a Linux distribution.

Does this change survive package re-installation?

It certainly takes no effect for newly installed packages.

How to reverse this?

What kind of feature breakage is to be expected?

Are there any alternative ways to implement this?

Are there any other linux distributions implementing this so we can look at their implementation for comparison?

1 Like

Likely, no as the package manager would give it back the setuid bit.

Create a list of all current setuid and setgid binaries before running this and then you can just give the setuid/setgid bit back to them.

A list of all setuid and setgid binaries can be gotten by running

find / -type f \( -perm -4000 -o -perm -2000 \)

Assuming you haven’t given the binary the required capabilities, it will not work. Some binaries like su will pretend to work but then always give a permission denied error.

We can create a list of common setuid and setgid binaries that are usually found on a system and remove their setuid/setgid bits individually. This way, we have a lot more control over what happens but there may be certain binaries that slip past.

Not that I know of.

The Arch Wiki has a page on this that may be useful.

https://wiki.archlinux.org/index.php/Capabilities

1 Like

Good ideas.

What about (re)-mount with nosuid [among other useful mount options]?

1 Like

That sounds like something that’d be good for /etc/fstab.d, similar to hidepid.

Mounting certain directories (/bin, /usr/bin etc.) would break many things with nosuid. Mounting directories like /home with nosuid may be useful but then it wouldn’t have any effect on the other setuid binaries.

We could use one of the methods above to remove setuid bits from most binaries and then use nosuid on directories like /home.

Using multiple different mount options for increased security would be a whole other topic.

1 Like

Good news. Debian seems to use capabilities over setuid bits for most default binaries. Things like ping don’t have setuid by default.

All binaries with setuid on a fresh Whonix installation are

/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/policykit-1/polkit-agent-helper-1
/usr/bin/chfn
/usr/bin/sudo
/usr/bin/passwd
/usr/bin/gpasswd
/usr/bin/pkexec
/usr/bin/newgrp
/usr/bin/firejail
/usr/bin/chsh
/bin/su
/bin/umount
/bin/mount

There are no setgid binaries by default.

firejail probably just needs CAP_SETUID and CAP_SETGID for user namespaces. Maybe CAP_SYS_ADMIN too but I’m not sure.

Some firejail commands will need others. For example, firejail --chroot will need CAP_SYS_CHROOT.

mount and umount will likely just need CAP_SYS_ADMIN.

su and sudo probably just need CAP_SETUID and CAP_SETGID.

These will need a lot of testing.

1 Like