Re: Providing an alternative to setuid in GuixSD

[Ludovic Courtès]

Hi!

address@hidden skribis:

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

Right.

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

Yes, I agree with this.

I think we must just be clear that GuixSD will be the only one to
benefit from a solution along the lines you wrote, at least for the
foreseeable future.

It seems to me that your proposal could be summarized as (1) replacing
sudo with a sudo-that-uses-IPCs (fine), and (2) replacing other setuid
programs by a wrapper that does “sudo program”.

Item #2 is already possible, but it doesn’t look “better” to me that
setuid programs from a security or configuration viewpoint.

Note that GuixSD is different from other distros regarding setuid
binaries: they exist only in /run/setuid-programs, which is recreated at
boot time (unless of course root messes up with the system).

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

What features do you have in mind?

Namespaces look like an improvement to me.  If you want something less
hacky, there’s always the Hurd.  ;-)

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

Polkit has its own sudo-like program, ‘pkexec’, that works by talking to
the polkit daemon over D-Bus.

Ludo’.