Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 1 May 2014 06:43:10 +0400
From: Solar Designer <solar@...nwall.com>
To: Steve Grubb <sgrubb@...hat.com>
Cc: oss-security@...ts.openwall.com, Andy Lutomirski <luto@...capital.net>
Subject: Re: local privilege escalation due to capng_lock as used in seunshare

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

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ