Providing an alternative to setuid in GuixSD

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!

Re: Providing an alternative to setuid in GuixSD

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 5025 bytes --]

Hi,

I don't think I have all the answers, but this is an interesting topic,
so I'll chime in with what I can.  I'm sure others will have more
thoughts to share, too.

sbaugh@catern.com writes:

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

When you say "filesystem namespacing functionality," are you referring
to the Linux feature known as "user namespaces"?  There is an article on
LWN that discusses some of the security issues surrounding this:

Filesystem mounts in user namespaces
https://lwn.net/Articles/652468/

I admittedly don't know a lot about this feature, but it sounds like it
is not currently designed to let a user escalate privilege in a way that
would enable malicious modification of system files such as /etc/passwd.
Can you clarify your second concern a little more to help me understand?

You might already know, but there appears to be prior work on the
general topic of eliminating setuid programs.  For example, see the
following paper, which surveys some of the programs and problems, and
even proposes a solution they call "Protego":

Practical Techniques to Obviate Setuid-to-Root Binaries
https://www3.cs.stonybrook.edu/%7Eporter/pubs/jain-setuid.pdf

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

It would be nice if the Guix daemon could create chroots for building
packages even when it runs as a non-privileged user.  That is definitely
a limitation (see the comment about "--disable-chroot" in (guix) Build
Environment Setup).  However, I don't understand how eliminating setuid
binaries would enable unprivileged access to root.  Can you clarify why
the latter follows from the former?

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

That's an interesting idea.  Some questions come to mind:

* How would we allow one user to run a program as a different user?

* How would we allow a user to update their own entries in shared
databases like /etc/passwd?

* Could this approach work with any kernel, not just Linux?

* Because the daemon must have enough privileges to take any potential
action that might be requested, does this solution fail to enforce the
principle of least privilege in basically the same way that many setuid
programs do (because they start with more privileges than they need)?

* Do you know of any prior art in this area which is similar to what you
are proposing?  I saw some interesting-looking references in the Protego
paper linked above, but I didn't go down the rabbit hole.

For what it's worth, the Nix/NixOS people have not (to my knowledge)
solved this problem, either.  They didn't mention any setuid
alternatives in any of the papers I checked here:

http://nixos.org/docs/papers.html

Best regards,

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Providing an alternative to setuid in GuixSD

[sbaugh]

Chris Marusich <cmmarusich@gmail.com> writes:
> Hi,
>
> I don't think I have all the answers, but this is an interesting topic,
> so I'll chime in with what I can.  I'm sure others will have more
> thoughts to share, too.
>
> sbaugh@catern.com writes:
>
>> 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.
>
> When you say "filesystem namespacing functionality," are you referring
> to the Linux feature known as "user namespaces"?

I was referring to things which correspond ~directly to chroot, like
mount namespaces or Plan 9 namespaces. But it's best to just consider
chroot I think.

The vulnerability is most clear when chroot is unprivileged, but it is
present in any system with setuid binaries and the ability to perform
non-trivial filesystem namespace manipulations without privileges. (In
particular, to change what the root directory points to)

Given chroot, all you need to do is:
1. Create your own filesystem tree with your own /etc/passwd and
/etc/shadow which specifies a known password for root.
2. Chroot into that filesystem tree
3. Run su and provide the known password for root; it will check the
password against the /etc/shadow that you created.
4. Escape the chroot. Once you have root in the chroot, there are many
mechanisms for doing this.  For example, create a device file
corresponding to the real root fs, mount it, and chroot again there.
5. Enjoy your new root privileges in the main filesystem namespace.

> There is an article on LWN that discusses some of the security issues
> surrounding this:
>
> Filesystem mounts in user namespaces
> https://lwn.net/Articles/652468/
>
> I admittedly don't know a lot about this feature, but it sounds like it
> is not currently designed to let a user escalate privilege in a way that
> would enable malicious modification of system files such as /etc/passwd.
> Can you clarify your second concern a little more to help me understand?

That's partially correct; user namespaces would not allow modification
of the "real" /etc/passwd, but they would allow you to create a mount
namespace where you can put whatever file you want in place of
/etc/passwd. In fact, you could get up to step 4 of the above attack.
But then you would be stuck: You are not supposed to be able to escape a
user namespace even with root, and while you are still inside a user
namespace your privileges don't mean anything.

So, user namespaces provide an alternative solution. But they also
independently expose quite a large attack surface, and I am not really
optimistic about them being accessible unprivileged in any mainstream
distro any time soon...

I am much more optimistic about the project of eliminating setuid
binaries and thereby allowing "plain old chroot" to be safely done
without privileges. This would only allow an a small subset of the
functionality of user namespaces, but it would be enough for a lot of
applications.

> It would be nice if the Guix daemon could create chroots for building
> packages even when it runs as a non-privileged user.  That is definitely
> a limitation (see the comment about "--disable-chroot" in (guix) Build
> Environment Setup).  However, I don't understand how eliminating setuid
> binaries would enable unprivileged access to root.  Can you clarify why
> the latter follows from the former?

Eliminating setuid binaries means step 3 in the above attack outline is
not possible. A distribution without setuid binaries could therefore
safely turn on unprivileged access to chroot.

>> == 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...
>
> That's an interesting idea.  Some questions come to mind:
>
> * How would we allow one user to run a program as a different user?

Well, if user A can authenticate as user B, they certainly can also run
a program as user B through normal ssh-like means. So I assume you mean
allowing user A to run a program as user B only by authenticating as
user A.  I believe that can be achieved with some ssh tricks. (I've done
just this with ssh and Kerberos principals before; I believe you could
do the same with ssh and Unix authentication but I haven't thought about
it in much detail so I'm waving my hands a bit here)

> * How would we allow a user to update their own entries in shared
> databases like /etc/passwd?

Through IPC to a privileged process: The "passwd" tool, as an example,
could simply send a message providing the new password to a daemon
privileged to perform the actual update.

Alternatively for case of passwd specifically, we could use the tcb
framework of Openwall: http://www.openwall.com/tcb/ Which is a somewhat
more elegant trick, but may be more work and less compatible. (I'm also
not sure that it works with absolutely all PAM modules; there could be
some besides the basic files authentication which anticipate running as
root. But I don't know for sure.)

> * Could this approach work with any kernel, not just Linux?

Definitely. As described currently it's totally kernel-independent.

At some point, file-descriptor-passing-over-Unix-sockets might be
useful. That would add a very small amount of kernel-dependence as that
is sometimes available in different ways on different Unix kernels. (But
it is still generally available.)

> * Because the daemon must have enough privileges to take any potential
> action that might be requested, does this solution fail to enforce the
> principle of least privilege in basically the same way that many setuid
> programs do (because they start with more privileges than they need)?

Yes. However, it's a big advance over setuid, because the daemon runs in
a fixed environment, rather than running in an environment entirely
controlled by an unprivileged user. And that is enough of an improvement
to get big benefits, namely, safe unprivileged chroot.

> * Do you know of any prior art in this area which is similar to what you
> are proposing?  I saw some interesting-looking references in the Protego
> paper linked above, but I didn't go down the rabbit hole.

Yes, there is some pre-existing software which is directly relevant:
- s6-sudod, which is explicitly for this purpose:
http://skarnet.org/software/s6/s6-sudod.html
- remctl, which is much older but could be usable for this purpose:
https://www.eyrie.org/~eagle/software/remctl/
- systemd's machinectl has a "shell" subcommand for getting a shell in
containers running on the local host, or on the local host itself:
https://www.freedesktop.org/software/systemd/man/machinectl.html

I don't know of any Unix/Linux distributions that really use this
approach. There's some similarity to Plan 9; Plan 9 has unprivileged
namespacing in part because it doesn't have setuid.

Of course, Guix is also an example of this IPC-to-privileged-action
approach: To perform the privileged action of isolating our builds, we
perform IPC to another more privileged process which does it for us.

Re: Providing an alternative to setuid in GuixSD

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

Re: Providing an alternative to setuid in GuixSD

[sbaugh]

ludo@gnu.org (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?

Re: Providing an alternative to setuid in GuixSD

[Christopher Allan Webber]

Ludovic Courtès writes:

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

I agree.  We could maybe have a pseudo-sudo service that is built just
for this purpose though... let's call it "psudo". ;)  Thinking out loud:

So, you're running psudo, and this thing maybe accepts connections over
something more secure, *maybe* unix domain sockets... so restrict group
access to the socket to users in the "psudo" group.

From there, maybe it could require PAM authentication while entering the
root password, or something.

It feels hard to know how psudo could "know" what user is accessing the
socket... I don't think that information is made available, right?
Maybe I'm wrong!  I guess postgres and etc do similar things?

Fun idea to think about anyway :)

Re: Providing an alternative to setuid in GuixSD

[sbaugh]

Christopher Allan Webber <cwebber@dustycloud.org> writes:
> So, you're running psudo, and this thing maybe accepts connections over
> something more secure, *maybe* unix domain sockets... so restrict group
> access to the socket to users in the "psudo" group.
>
> From there, maybe it could require PAM authentication while entering the
> root password, or something.
>
> It feels hard to know how psudo could "know" what user is accessing the
> socket... I don't think that information is made available, right?
> Maybe I'm wrong!  I guess postgres and etc do similar things?

On Linux, there is SCM_CREDENTIALS (and similar stuff on BSDs). From
Linux unix(7):

SCM_CREDENTIALS
Send or receive UNIX credentials.  This can be used for authentication.
The credentials are passed as a struct ucred ancillary message.  Thus
structure is defined in <sys/socket.h> as follows:

           struct ucred {
               pid_t pid;    /* process ID of the sending process */
               uid_t uid;    /* user ID of the sending process */
               gid_t gid;    /* group ID of the sending process */
           };

Moreover there is the Polkit (ne PolicyKit) framework for this kind of
stuff, which could provide a more high-level interface if we chose to
use it. (GNOME uses it as does systemd)

(Note that there is already pkexec (bundled with Polkit) which provides
a sudo replacement with authentiation and policy through Polkit. But
it's setuid for some reason. I haven't investigated why...)

Re: Providing an alternative to setuid in GuixSD

[Ludovic Courtès]

Hi!

sbaugh@catern.com skribis:

> ludo@gnu.org (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’.

Re: Providing an alternative to setuid in GuixSD

[sbaugh]

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.