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
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ