Re: Providing an alternative to setuid in GuixSD

[sbaugh]

address@hidden (Ludovic Courtès) writes:
> Well, the kernel Linux will forever support setuid binaries

That can be selectively turned off per-mount, simply specify the nosuid
option. And so eventually we can get to a point where setuid is a Linux
build configuration option, which distros can turn off.

> and thus, most likely, chroot(2) will forever be restricted to root.

This too can be a configuration option. And it's entirely possible for
distros to turn it on after setuid is turned off.

These decisions about setuid and chroot are distribution decisions;
distributions can and should make decisions and innovate independent of
the Linux kernel's default configuration. (That's part of how the whole
GNU/Linux ecosystem works)

On another point, even if chroot is forever privileged, new syscalls can
be developed which duplicate the functionality of chroot with more
flexibility and less baggage. But they will certainly face the same
issue as chroot if they wish to be made unprivileged. Mount namespaces,
for example, (with a bit of tweaking of the API to make it actually
useful unprivileged) could be made unprivileged without relying on user
namespaces, but face the same problems as chroot. So by removing setuid
we are laying the groundwork for innovation not just by allowing
unprivileged chroot.

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

I mean new kernel features - I'm skeptical that user namespaces provide
an intuitive or easy to use API, and I have some ideas on what would be
better. But the features I want to develop rely on getting rid of
setuid, so I'm starting there. :)

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

Yes, that is true. The sole virtue of ssh here is that it already exists
and is used for this purpose.

What if we adapted s6-sudod, or wrote something from scratch? Or perhaps
patched sudo to work in some way over IPC? I think a generic solution is
useful. Maybe something should be written specifically for GuixSD,
configured with Guile? Or maybe something which makes use of the putative
standard, PolicyKit, which is configured with Javascript?