[PATCH] LSM: add SafeSetID module that gates setid calls

[Micah Morton]

On Wed, Oct 31, 2018 at 3:37 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
>
> On 10/31/2018 2:57 PM, Kees Cook wrote:
> > On Wed, Oct 31, 2018 at 2:02 PM, Serge E. Hallyn <serge at hallyn.com> wrote:
> >> Just to be sure - your end-goal is to have a set of tasks which have
> >> some privileges, including CAP_SETUID, but which cannot transition to
> >> certain uids, perhaps including root?

Correct, only whitelisted uids can be switched to. This only pertains
to CAP_SETUID, other capabilities are not affected.

> > AIUI, the issue is that CAP_SETUID is TOO permissive. Instead, run
> > _without_ CAP_SETUID and still allow whitelisted uid transitions.

Kees is right that this LSM only pertains to a single capability:
CAP_SETUID (future work could tackle CAP_SETGID in the same fashion)
-- although the idea here is to put in per-user limitations on what a
process running as that user can do even when it _has_ CAP_SETUID. So
it doesn't grant any extra privileges to processes that don't have
CAP_SETUID, only restricts processes that _do_ have CAP_SETUID if the
user they are running under is restricted.

>
> I don't like that thought at all at all. You need CAP_SETUID for
> some transitions but not all. I can call setreuid() and restore
> the saved UID to the effective UID. If this LSM works correctly
> (I haven't examined it carefully yet) it should prevent restoring
> the effective UID if there isn't an appropriate whitelist entry.

Yep, thats how it works. The idea here is that you still need
CAP_SETUID for all transitions, regardless of whether whitelist
policies exist or not.

>
> It also violates the "additional restriction" model of LSMs.
>
> That has the potential to introduce a failure when a process tries
> to give up privilege. If 0:1000 isn't on the whitelist but 1000:0

As above, if a process drops CAP_SETUID it wouldn't be able to do any
transitions (if this is what you mean by give up privilege). The
whitelist is a one-way policy so if one wanted to restrict user 123
but let it switch to 456 and back, 2 policies would need to be added:
123 -> 456 and 456 -> 123.

> is Bad Things can happen. A SUID root program would be unable to
> give up its privilege by going back to the real UID in this case.
>