Re: Providing an alternative to setuid in GuixSD

[sbaugh@catern.com]

ludo@gnu.org (Ludovic Courtès) writes:
> 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.

Well, I am slightly more optimistic than that. It may be that this
solution is such a success that other distros emulate us. :) But, yes,
there is no clear path for this work to be used by anything but GuixSD
(and NixOS). I think that is fine; we should not fear to innovate.

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

Yes.

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

Right, item #2 is only useful when it allows actually getting to the
0-setuid-binaries state; that is, item #2 requires that item #1 has
already been achieved to be useful.

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

They're definitely an improvement. Don't get me wrong, I am absolutely
excited about user namespaces.

But they have a lot of drawbacks. They expose a huge amount of
formerly-privileged APIs to unprivileged processes, causing security
problems. They require system-wide configuration and allocation of uids
for the UID mapping. Working across multiple namespaces isn't possible
and if it ever is possible it will probably require making the whole
thing even more complicated. And finally it's just rather weird to have
to create a different user namespace, gain pseudo-root, and execute
syscalls using fake capabilities just to manipulate your view of the
filesystem. Indeed I prefer the Hurd here. :)

If we get rid of setuid binaries in userspace, these kernel APIs can be
redesigned in a simpler and more powerful way. To improve the GNU/Linux
system we can't just rely on kernel development: We must also develop
userspace to open up paths forward.

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

I don't want to prescribe any specific set of features.  Unprivileged
chroot or equivalent, without having to first go through user
namespaces, would be a start. In combination with unprivilegd bind
mounts it would give us quite a lot of what we need.

If I had to be specific about features, I would say that it would be
nice to port an API like Plan 9 namespaces to Linux. (Hurd-like features
would also be acceptable.) Perhaps this is overly optimistic.

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

I've investigated this. pkexec requires being setuid: it only does
authentication with polkit; it actually runs things just like sudo, by
setreuid and exec, rather than telling a daemon to run it.