Date: Thu, 1 May 2014 07:06:37 +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 Thu, May 01, 2014 at 06:43:10AM +0400, Solar Designer wrote: > 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"), Actually, I think it won't work well for that unless the distro in question doesn't use any SUID root programs that need capabilities, because SECURE_NOROOT breaks the raising of capabilities for SUID root exec (on purpose). So generic implementations of containers capable of running arbitrary Linux distro userlands are probably not making use of SECURE_NOROOT. > 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? Per my quick greps, this does not appear to be the case. The only checks for SECURE_NOROOT that I could find are in cap_bprm_set_creds(), so SECURE_NOROOT should affect execve(2), but not setuid(2). Why are we talking about it in this context, then? 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