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

[Solar Designer <solar () openwall com>]

On Wed, Apr 30, 2014 at 09:27:10PM -0400, Steve Grubb wrote:
> And switching to NO_NEW_PRIVS broke the sandbox:
> https://bugzilla.redhat.com/show_bug.cgi?id=1091761
>
> So, perhaps fixing SECURE_NOROOT is the safest bet? Are there any other 
> opinions on this?

If SECURE_NOROOT is meant to be usable to run entire Linux distros
(whether "on host" or/and "in containers"), then it must not have an
effect of excluding UID 0 from "appropriate privileges" for setuid(2).

Do we know reliably that in this case excluding UID 0 from "appropriate
privileges" for setuid(2) was an effect specifically of SECURE_NOROOT?
If so, yes, it sounds like it needs to be fixed, and this detail needs
to be documented.

Do any implementations of containers, such as LXC, rely on
SECURE_NOROOT?  If so, it sounds like they might have extra local root
vulnerabilities (for in-container user to in-container root) as a result
of this issue.

I also suggest that distros don't make things like seunshare available
to non-administrator users by default, because these expand the attack
surface even if an attempt is made to make them safe.  Only a subset of
systems will benefit from having this functionality exposed by default,
whereas all systems will suffer from the expanded attack surface.

Alexander