Providing an alternative to setuid in GuixSD

[sbaugh]

Hi guix-devel,

Has any effort been put into eliminating the need for setuid binaries
from GuixSD? I would be interested in working on that.

== 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. So I think it only right that we should take the
necessary steps to support it in GuixSD. Then maybe (in a decade or
so...) it'll be picked up by Debian and other large distributions.

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.)

== 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...

Does this plan makes sense in the context of GuixSD? Am I leaving out
anything?
Thanks!