Hello! sba...@catern.com skribis:
> == Why remove setuid binaries? == > > setuid binaries are problematic for two reasons: > > 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. > > 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. Well, the kernel Linux will forever support setuid binaries and thus, most likely, chroot(2) will forever be restricted to root. So I think removing setuid binaries on GuixSD is helpful for GuixSD itself, but not for other distros (at least not directly so). > I think also the ability to build a setuid-free system could make GuixSD > a useful platform for innovation in the use of filesystem namespaces. (I > myself certainly have plans in this area.) Our ‘linux-libre’ package has support for user namespaces and other namespaces built in already (this is the default kernel config I think), so one can already play with namespaces on GuixSD and on other distros that enable it. :-) > == 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 SSH is a complex protocol and its implementations are complex too. I would find it unreasonable to replace ‘su’ and ‘sudo’ with something this complex, that goes through the TCP/IP stack, etc. > Does this plan makes sense in the context of GuixSD? Am I leaving out > anything? I don’t know, I’m skeptical! :-) However, I agree that GuixSD has more latitude as to how it deals with privileges, notably because the set of users, setuid binaries, and other relevant bits is all described in ‘operating-system’. Ludo’.
