Re: local privilege escalation due to capng_lock as used in seunshare

[Solar Designer <solar () openwall com>]

On Wed, Apr 30, 2014 at 11:55:31AM -0400, Steve Grubb wrote:
> In my opinion, the issue is that I think SECURE_NOROOT doesn't get its 
> semantics right as is. I'm thinking if noroot is set and cap_setuid is set, 
> suid should be as normal but with no capabilities. If noroot is set and 
> cap_setuid is unset, no transition of any uid should occur. If noroot is 
> unset, then works as normal.

Of the three cases above, only the "noroot is set and cap_setuid is
unset" case currently has semantics different from what you propose,
and the rest are already as you described, correct?

Is my understanding correct that setuid(2)'s "appropriate privileges"
end up being altered via lacking CAP_SETUID, even though we do gain UID 0
during the SUID root exec?  This appears consistent with the code.

If so, we may either prevent this combination of settings from occurring
(in the way you describe or otherwise) or maybe we should fix setuid(2)
(and a few others?) to treat the lack of CAP_SETUID differently.

IIRC, the "sendmail bug" was fixed in the kernel by requiring privileges
to drop capabilities, so an attacker wouldn't simply drop CAP_SETUID.
Your proposed change is in line with that, but the behavior feels
hackish and unexpected.  That said, Linux 2.4+ already set the precedent
of ignoring SUID/SGID in some cases, yet proceeding with exec, so it
won't be a new bad thing (rather, more of the moderately old bad thing).

Sorry for so many messages.  It's been years since I looked at this code
closely, so it takes a while to recall what it's about.

Alexander