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

[Serge E. Hallyn]

Quoting Casey Schaufler (casey at schaufler-ca.com):
> On 11/2/2018 11:30 AM, Serge E. Hallyn wrote:
> > Quoting Casey Schaufler (casey at schaufler-ca.com):
> >
> >> Let me suggest a change to the way your LSM works
> >> that would reduce my concerns. Rather than refusing to
> >> make a UID change that isn't on your whitelist, kill a
> >> process that makes a prohibited request. This mitigates
> >> the problem where a process doesn't check for an error
> >> return. Sure, your system will be harder to get running
> >> until your whitelist is complete, but you'll avoid a
> >> whole category of security bugs.
> > Might also consider not restricting CAP_SETUID, but instead adding a
> > new CAP_SETUID_RANGE capability.  That way you can be sure there will be
> > no regressions with any programs which run with CAP_SETUID.
> >
> > Though that violates what Casey was just arguing halfway up the email.
> 
> I know that it's hard to believe 20 years after the fact,
> but the POSIX group worked very hard to ensure that the granularity
> of capabilities was correct for the security policy that the
> interfaces defined in P1003.1. What would CAP_SETUID_RANGE mean?

CAP_SETUID would mean you can switch to any uid.

CAP_SETUID_RANGE would mean you could make the transitions which have
been defined through <handwave> some mechanism.  Be it prctl, or some
new security.uidrange xattr, or the mechanism Micah proposed, except
it only applies for CAP_SETUID_RANGE not CAP_SETUID.

-serge