[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140501030637.GA24836@openwall.com>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
