[<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
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.
