Re: Re: local privilege escalation due to capng_lock as used in seunshare

[Steve Grubb <sgrubb () redhat com>]

On Wednesday, April 30, 2014 04:07:19 PM Andy Lutomirski wrote:
> On 04/30/2014 08:55 AM, Steve Grubb wrote:
> > On Wednesday, April 30, 2014 02:35:52 AM Solar Designer wrote:
> > > On Tue, Apr 29, 2014 at 06:18:58PM -0400, Steve Grubb wrote:
> > > > On Wednesday, April 30, 2014 02:12:22 AM Solar Designer wrote:
> > > > > On Tue, Apr 29, 2014 at 05:49:04PM -0400, Steve Grubb wrote:
> > > > > > On Tuesday, April 29, 2014 02:20:47 PM Andy Lutomirski wrote:
> > > > > > >   if (setuid(getuid()) != 0)
> > > > > > >   
> > > > > > >     err(1, "setuid(getuid())");
> > > > > >
> > > > > > If you do not want the saved uid to be available, you need to use
> > > > > > setresuid. That removes it. I would classify this as a bug in the test
> > > > > > program.
> > > > >
> > > > > Not quite.
> > > >
> > > > If the program was amended to use setresuid(), does the bug still exist?
> > >
> > > Yes, because it affects other similar correct programs that haven't yet
> > > been amended to work safely on your non-Unix system. ;-)  Alternatively,
> > > you may declare that your system is deliberately incapable of running
> > > programs written for traditional Unix safely, and will stay that way.
> > > That will be a reason for people to prefer other Linux distros over Red
> > > Hat's, but at least it'd be fair. ;-(
> > >
> > > To paraphrase your question, since sendmail got a workaround for the old
> > > capabilities bug in the Linux kernel, does the bug in those old kernel
> > > versions still exist?  The answer is also yes, it does, potentially
> > > affecting other programs running on those vulnerable kernels.(*)  The
> > > bug needed to be fixed in the kernel, and it was (for later versions).
> > >
> > > (*) Of course, most people should not actually run those old kernels
> > > because of other vulnerabilities that have been found and fixed since,
> > > but that's a separate matter.
> > >
> > > I hope you don't mind the rhetoric.  I mean it to be friendly.  I hope
> > > it serves to deliver the message well.
> >
> > No problem. I chatted with Petr Matousek about this and I think we
> > understand the issue now.
> >
> > In my opinion, the issue is that I think SECURE_NOROOT doesn't get its
> > semantics right as is. I'm thinking if noroot is set and cap_setuid is
> > set,  suid should be as normal but with no capabilities. If noroot is set
> > and cap_setuid is unset, no transition of any uid should occur. If noroot
> > is unset, then works as normal.
> >
> > If this was not the intention, then SECURE_NOSUID should have been created
> > at the same time the other SECUREBITS options were created so that each
> > part of credential change could be completely controlled. Not designing
> > the ability to control all parts is what creates this hole...for years I
> > might add.
> >
> > So, I wonder if SECURE_NOROOT should be fixed or if ancient kernels need
> > to suddenly backport PR_SET_NO_NEW_PRIVS?
>
> I suspect that fixing SECURE_NOROOT will be basically impossible.  I'm
> not sure that anyone knows what it's supposed to do, and there is an
> amazing amount of inertia preventing any changes to Linux's capability
> system.
>
> I'd support an effort to kill securebits, but that might also be impossible.
>
> Backporting PR_SET_NO_NEW_PRIVS would be easy, but I don't know how many
> people are still supporting kernels that don't have it.  IIRC it was
> added in Linux 3.5.  I guess RHEL5 and RHEL6 could be candidates.  TBH
> it might actually be safer to turn off securebits entirely in capng_lock
> -- I suspect that the class of attacks enabled by setting securebits is
> larger than the class that is mitigated.
>
> For distros that are affected (SUSE/OpenSUSE?), the latest upstream
> cap-ng is now patched to use PR_SET_NO_NEW_PRIVS.

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?

-Steve