[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

Edit by Patrick:
See also (re-)mount home [and other?] with noexec (and nosuid [among other useful mount options]) for better security?

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]?

Edit by Patrick:
Created (re-)mount home [and other?] with noexec (and nosuid [among other useful mount options]) for better security? for it.

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.

Edit by Patrick:
Created (re-)mount home [and other?] with noexec (and nosuid [among other useful mount options]) for better security? for it.

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

Alternatively, could we identify suid binaries and then run chmod o-x [0] on them. I.e. o (“others”) (i.e. user user) may not execute them. In result only root could execute suid binaries but non-root could not. Would that help to reduce the risk of suid binaries?

Tested. It’s possible to remove executable permission for binaries for others (user user) while root can still execute the binary.

Either,

  • chmod all suid binaries except a whitelist [1], OR
  • we manually maintain a blacklist of suid binaries (the ones shipped by default but we want to disable). [2]

That would prevent non-root users from executing suid binaries.

A dpkg hook or something could re-apply these changes on upgrades. But not great since malware could wait for the upgrade to happen and there would a vulnerable time window between package upgrade and suid re-disable.

Maybe ACL or something similar could enforce keeping the file permissions (chmod o-x) during upgrades?


[0] Or chmod og-x or chmod o-rx or chmod og-rwx or something?

[1] In a noroot boot mode, even sudo could be set to chmod o-x since during such sessions the user decided to trade sudo not being accessible for better security.

[2] On top, there could be a tool to search and warn against newly installed suid binaries.

1 Like

The entire point of SUID binaries are so unprivileged users can do some privileged operations so why not just remove the SUID bit instead?

This seems like the best approach as it would have minimal breakage.

The whitelist idea would be more effective in ensuring only needed SUID binaries can be executed but then it would break binaries a user creates themselves.

Unless there’s something we can make that checks if a new SUID binary has been created and says “SUID binaries are not allowed by default, see https://www.whonix.org/wiki/wiki_page and whitelist your binary” or something like that.

1 Like

Didn’t have this in mind indeed. Therefore also chmod u-s would do. chmod u-s would not limit root from using these binaries.

However, making these binaries non-executable (and/or non-readable) might have another advantage: we fail closed and loudly (with error message) rather than leading to stranger to interpret issues, such as:

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]