Re: Providing an alternative to setuid in GuixSD

[Chris Marusich]

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.

address@hidden 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

signature.asc
Description: PGP signature