Date: Sun, 2 May 2021 11:40:19 -0400 From: Felix Kyros Ang <felixk@...aven.com> To: musl@...ts.openwall.com Subject: Consider making issetugid compatible with Linux capabilities Hello, Musl implements the BSDs' issetugid syscall as a libc function (which is awesome). Currently, musl's issetugid indicates that the environment is tainted when it detects additional Linux capabilities on the executable (set through setcap for example). This causes the environment to be cleared when the executable is run, leading to some program breakages. For instance, some libdbus functions use the environment to identify the dbus session bus ID, and those programs (linked to libdbus) will fail if Linux capabilities are added to it. I wonder if it would be possible to tweak musl such that it does not consider Linux capabilities a tainted privilege. Alternatively, it could consider only the "highly overloaded" capabilities (such as CAP_SYS_ADMIN) as tainted privileges. Here are my thoughts on why this could be a good idea: - The main purpose of capabilities is to add granular access control mechanisms for sys administration in Linux, as opposed to the "traditional" Unix black-and-white superuser model. The attack surface is reduced, because programs may be granted only the elevated permissions that they need to perform their function, as opposed to the "full/complete" set of superuser privileges. - By treating capabilities as equivalent to superuser privileges, programs are forced to take up root privileges (e.g. they need to be run as root or with sudo) in order to perform their intended operations. This seems to defeat the purpose of adding granular role-based access control mechanisms through capabilities in the first place, and has the unfortunate consequence of re-opening the attack surface again. Some comparisons with the BSDs' behaviours seem to also support such a change: - FreeBSD's issetugid checks if setuid and setgid bits are set, and if the process's owner has been changed since program invocation which could suggest a potential attempt at privilege escalation. Role-based access controls are managed through the MAC mechanism, and this appears to be compatible with issetugid (please correct me if I'm wrong). - OpenBSD keeps the old superuser model (making it important to be as conservative as possible when calling issetugid). However, OpenBSD uses pledge and unveil to *remove* privileges from superuser programs (as opposed to grant additional privileges them on non-root executables) to achieve the same effect. issetugid seems to be particularly focused on process ownership changes since program invocation (particular ownership changes from lower to unqualified superuser privs - from user to root) as happens with a setuid binary. It seems reasonable to consider a binary that already has a Linux capability set to be invoking only that limited subset of known privileges, and not be performing the equivalent of taking on an "unknowable euid". If so, musl could explicitly decide which capabilities it does or does not trust (like cap_sys_admin) when returning whether the process is attempting to run as root or not. Looking at the code, it looks like musl's issetugid function returns the libc.secure value when called, and I couldn't find where libc.secure's value is initialised. If someone could point me in the right direction, I'll see if I can maybe send in a patch that proposes a possible solution. Thanks for your time. Looking forward to your thoughts. Cheers, Felix
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.