Hi, I don't think I have all the answers, but this is an interesting topic, so I'll chime in with what I can. I'm sure others will have more thoughts to share, too.
sba...@catern.com writes: > 1. Each binary is an attack surface which is frequently exploited by > attackers for local privilege escalation. So getting rid of them > would improve security. > > 2. setuid binaries make access control decisions in an environment > controlled by the user running them, by looking at files at absolute > paths in that environment, such as /etc/passwd. Thus, if unprivileged > users had access to chroot or other filesystem namespacing > functionality, those users could escalate privileges by manipulating > /etc/passwd, /etc/shadow, /etc/sudoers, and then running a setuid > binary. So unprivileged chroot is not possible. When you say "filesystem namespacing functionality," are you referring to the Linux feature known as "user namespaces"? There is an article on LWN that discusses some of the security issues surrounding this: Filesystem mounts in user namespaces https://lwn.net/Articles/652468/ I admittedly don't know a lot about this feature, but it sounds like it is not currently designed to let a user escalate privilege in a way that would enable malicious modification of system files such as /etc/passwd. Can you clarify your second concern a little more to help me understand? You might already know, but there appears to be prior work on the general topic of eliminating setuid programs. For example, see the following paper, which surveys some of the programs and problems, and even proposes a solution they call "Protego": Practical Techniques to Obviate Setuid-to-Root Binaries https://www3.cs.stonybrook.edu/%7Eporter/pubs/jain-setuid.pdf > Issue 2 is a matter near and dear to our hearts here in guix-land, and > is my primary motivation. My understanding is that if we eliminated > all setuid binaries, we could with some confidence begin to allow > unprivileged access to chroot/filesystem namespaces, without first > going through user namespaces (which have their own issues). Please > correct me if you believe this is wrong. > > Unprivileged access to chroot would of course greatly aid unprivileged > installation of guix. It would be nice if the Guix daemon could create chroots for building packages even when it runs as a non-privileged user. That is definitely a limitation (see the comment about "--disable-chroot" in (guix) Build Environment Setup). However, I don't understand how eliminating setuid binaries would enable unprivileged access to root. Can you clarify why the latter follows from the former? > == How to do it == > > Most (all?) setuid binaries can be replaced with a non-setuid binary > which performs local IPC to a privileged daemon. > > The largest targets for elimination are sudo and su. Luckily there is > already a ready alternative for those commands: ssh. We can augment lsh > with the rich access controls of sudo, add any extra missing features, > and then replace sudo/su with wrappers around ssh. (A wrapper would be > needed just for sheer familiarity of the system to a user.) sshd runs > and performs access controls in a fixed environment, so this is not > vulnerable to the chroot attack I mentioned above. > > Once we have a solid replacement for sudo, we can take a generic > approach to eliminating other setuid binaries: just replace them with > wrappers which call 'sudo command "$@"', and make sure the > sudo-replacement is appropriately configured to allow running that > command without authentication. > > I believe we could do this with all binaries, though there may be some > issues I'm not yet aware of yet. > > In the longer term I'm not sure if we would want to individually > replace setuid binaries with IPC-performing commands. The only real > benefit is maybe elegance... That's an interesting idea. Some questions come to mind: * How would we allow one user to run a program as a different user? * How would we allow a user to update their own entries in shared databases like /etc/passwd? * Could this approach work with any kernel, not just Linux? * Because the daemon must have enough privileges to take any potential action that might be requested, does this solution fail to enforce the principle of least privilege in basically the same way that many setuid programs do (because they start with more privileges than they need)? * Do you know of any prior art in this area which is similar to what you are proposing? I saw some interesting-looking references in the Protego paper linked above, but I didn't go down the rabbit hole. For what it's worth, the Nix/NixOS people have not (to my knowledge) solved this problem, either. They didn't mention any setuid alternatives in any of the papers I checked here: http://nixos.org/docs/papers.html Best regards, -- Chris
signature.asc
Description: PGP signature
