linux-kernel - Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151105161512.GA2180@mail.hallyn.com>
Date:	Thu, 5 Nov 2015 10:15:12 -0600
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	Klaus Ethgen <Klaus+lkml@...gen.de>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Richard Weinberger <richard.weinberger@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Christoph Lameter <cl@...ux.com>,
	Andy Lutomirski <luto@...nel.org>,
	Serge Hallyn <serge.hallyn@...ntu.com>,
	Kees Cook <keescook@...omium.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems
 using capabilities

On Thu, Nov 05, 2015 at 11:19:54AM +0100, Klaus Ethgen wrote:
> Hi,
> 
> sorry for the delay.
> 
> Am Mo den  2. Nov 2015 um 20:45 schrieb Andy Lutomirski:
> > > Well, the think that changed is that the ambient capabilities can be set
> > > by any process if the pI and pE are matching for a process. But then,
> > > that capabilities are inherited via execve to even programs that don't
> > > have any capability setting. That allows every subprocess to (mis-)use
> > > it.
> > 
> > That's true.  I don't see why it's a problem, given that the parent
> > can already use or mis-use it however it wants, and the child won't
> > get the capability without explicit action by the parent.
> 
> Well the parent can but usually is not aware of to what it gives this
> ambient capabilities to.

If it sets ambient caps, then it is exactly agreeing to not be aware
what it's giving ambient caps to.

Maybe the capabilities manpage updates need to be more strongly slanted
toward "if you *can* use pI|fI then you really should do so".

> Exactly here is the point. There are many applications out there that
> needs to be SUID root. Many of them only cause the developer has
> something inside like "if getuid() != 0". So in future I suspect many of
> such tools that even don't need to give capabilities to childs, are
> setting all available capabilities in ambient capabilities before
> starting do do something.

Well, maybe what's really needed is a capabilities project that works with
any upstreams wanting to support a capabilities-only mode to help them
do things the right way.  I'd happily help out with that.

> With the present way, that was no problem (for OSS). You take away the
> SUID, set the capabilities and if the tool complains about not being
> root, look into the code and remove that stupid thing. With ambient
> capabilities, no one will see that the tool is doing such stupid thing
> as setting all capabilities unless some trouble is seen.
> 
> And I don't see that as hypothetical. I know many developer who are
> misusing sudo as it is introduced by ubuntu by doing:
> "sudo less /etc/hosts"
> "sudo cd /bla"
> "sudo ls"
> 
> and so on. Do you really expect such developer being sensitive to use
> capabilities carefully? I don't. With the capabilities until now there
> was a great tool for the admin to limit damage that can be done with
> SUID by replacing it with proper capabilities. Now, with the new ambient

I think if you follow your idea to its logical conclusions, you end
up wanting set SECURE_ALL_BITS | SECURE_ALL_LOCKS, which will include
SECURE_NO_CAP_AMBIENT_RAISE, disabling ambient capabilities.

I strongly support people working towards that.

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/