Re: Providing an alternative to setuid in GuixSD

[ludo@gnu.org (Ludovic Courtès)]

Hello!

sbaugh@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’.