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 07:06:37 +0400
From: Solar Designer <>
To: Steve Grubb <>
Cc:, Andy Lutomirski <>
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:
> >
> > 
> > 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

> 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?


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