Rethinking SUID-root binaries #866
Comments
|
@ok-ryoko hello and welcome! and than you very much for your work 😄
Yes certainly
Fortunately, we don't need this currently except for chfn. secureblue's approach is currently to fully remove suid-root binaries if possible. If that's not possible, then strip suid.
What changes do you have in mind? Polkit agent helper will no longer require suid once this merges and ships polkit-org/polkit#501 And the only places where we use caps are:
|
If chfn(1), ssh-keysign(8), and fusermount3(1) were made SUID-root, then the appropriate capability sets would be as follows: set_caps_if_present "cap_chown,cap_audit_write=ep" "/usr/bin/chfn"
set_caps_if_present "=" "/usr/libexec/openssh/ssh-keysign"
set_caps_if_present "cap_dac_read_search,cap_sys_admin=ep" "/usr/bin/fusermount3"In this case, it’d also be appropriate to rename setcapsforunsuidbinaries to setcapsforsuidbinaries and propagate that rename. However, if it’s secureblue’s policy to avoid SUID-root execution, then these changes are not viable.
Good to know!
Out of the five applications listed in setcapsforunsuidbinaries, the only ones I know to be critical to Fedora Linux/GNOME functionality (based on my experience) are unix_chkpwd(8) and fusermount3(1). I appreciate your quick reply. |
Well, it depends. If I understand your concern correctly, it's that although using caps instead of suid reduces the maximum privileges a binary can have, it might also increase the minimum privileges of that binary, by making it incapable of dropping privileges (as it does when suid-root). If this is correct, I think it would be best to approach it on a case by case basis, asking the following questions:
Let me know your thoughts |
Certainly. I’ve sketched some analyses below based on the sources for and traces of the Fedora Linux 41 1.4 versions of the binaries. /usr/bin/chage: For /usr/bin/chfn: For updating finger information, requires /usr/libexec/openssh/ssh-keysign: To support host-based authentication via ssh(1), requires no capabilities when running SUID-root, otherwise requires /usr/bin/fusermount3: For mounting and unmounting FUSE filesystems, requires /usr/sbin/unix_chkpwd: To support the On the basis of just these observations, and without reference to any particular threat model, it does seem less risky to run some of these binaries non-SUID-root when aiming to minimize attack surface. I’d prioritize removing privileges from chfn(1) as secureblue already does for chsh(1). If you wanted to remove the binary altogether, usermod(8) could help fill the gap: $ run0 usermod -c COMMENT LOGIN… although this would require users to remember the structure of the GECOS field. |
|
On modern Linux dropping privileges doesn't just mean changing uid/gid, it can also be done via LSMs such as Landlock. This would work great for cases like unix_chkpwd that only need access to one or two fixed files that are privileged, and nothing else. So a file-based capability for reading/writing plus Landlock to restrict access to only those two files should be feasible and remove the need for suid. |
This seems like the most critical of the issues you listed. Is the best option available to add back suid? Seems like a lose-lose.
I'm inclined to do so but it would require documenting how to use usermod in its place, in an FAQ item. |
I recently revisited my research of SUID-root binaries in Fedora Linux and would like to bring several key changes to secureblue’s attention.
To make my work easier to read, navigate, and maintain, I moved away from monolithic and incremental gists to a Git repository at https://git.sr.ht/~megumi/fedora-suid. secureblue is, to my knowledge, the only project using my work at this time. I would find your feedback on the new format and content especially valuable, although there’s no obligation to give any. In any case, the reference in removesuid.sh should be updated accordingly.
I also developed a fork of strace(1) to print capability checks that I then applied to help refine my findings and add new reference use cases. I hope that it can help distro maintainers like yourself reach independent conclusions about capabilities.
Importantly, I revised my position on SUID-root execution. I’d previously operated on the premise that the SUID bit could and should be substituted with file capabilities. However, I now think that file capabilities should be set only to supplement the SUID bit on capabilities-unaware binaries.
SUID-root programs make UID transitions to drop privileges either temporarily or permanently. Unsetting the SUID bit makes certain respective setuid(2), setreuid(2), etc. calls no-ops. The only option that the program has to drop privileges is then to immediately execve(2) an unprivileged program, which isn’t guaranteed.
As well, unsetting the SUID bit imposes a requirement for additional powerful capabilities such as
CAP_DAC_OVERRIDEto compensate for the concomitant mismatch in EUIDs when interaction with files and directories owned by root is necessary.I’d be happy to submit a pull request making the requisite changes. I started by opening an issue because I believe that it’s more important to achieve a consensus on next steps, given how challenging it can be to reason about these topics all at once.
Thank you again for all your work!
The text was updated successfully, but these errors were encountered: