Re: [KERNEL] Re: [KERNEL] [PATCH] Kernel 4.3 breaks security in systems using capabilities

From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: "Theodore Ts'o" <tytso@mit.edu>,
	Andy Lutomirski <luto@amacapital.net>,
	Serge Hallyn <serge.hallyn@ubuntu.com>,
	Kees Cook <keescook@chromium.org>,
	Christoph Lameter <cl@linux.com>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Richard Weinberger <richard.weinberger@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [KERNEL] Re: [KERNEL] [PATCH] Kernel 4.3 breaks security in systems using capabilities
Date: Tue, 10 Nov 2015 15:39:52 -0500	[thread overview]
Message-ID: <56425618.6060703@gmail.com> (raw)
In-Reply-To: <20151110175849.GB26726@ikki.ethgen.ch>

[-- Attachment #1: Type: text/plain, Size: 4200 bytes --]

On 2015-11-10 12:58, Klaus Ethgen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Am Di den 10. Nov 2015 um 14:35 schrieb Austin S Hemmelgarn:
>> On 2015-11-10 08:19, Klaus Ethgen wrote:
>>> Hi Ted, hy others in this discussion,
>>>
>>> Am Di den 10. Nov 2015 um 13:40 schrieb Theodore Ts'o:
>>>> Whether or not that will be acceptable upstream, I don't know, mainly
>>>> because I think a strong case can be made that such a patch has an
>>>> audience of one, and adding more complexity here for an idea which has
>>>> been time-tested over decades to be a failure is just not a good idea.
>>>
>>> I wouldn't tell the implementation until now to be a failure. It helped
>>> a lot to keep a system sane. It is true that all distributions ignored
>>> capabilities completely but I don't think that is due the design.
>> I think it's mostly due to the fact that there are a lot of potential
>> security issues in using capabilities as implemented in Linux (and other
>> POSIX systems),
>
> Well, of course. If you give a process capabilities, it can use it. That
> is in the nature of the problem. But in comparison to SUID, it is
> selective rights. That makes it much more troublesome to exploit. Why
> the hell is, for example, ping installed SUID root? There is only one
> privileged right that is needed instead of all or nothing.
FWIW, on Hardened Gentoo, ping is installed without the SUID bit set, 
and has the appropriate fscaps attribute to give it CAP_NET_RAW. Sadly, 
that's about the only tool that is set to use capabilities (the only 
other one I know of is arping). Ping is however very purpose specific 
and short of someone re-writing the binary, there really isn't much that 
could be done to use it for privilege escalation. OTOH even when you use 
capabilities, it's pretty easy for someone with a little shell scripting 
knowledge to preform a DOS attack on a network just using ping.
>
>> and unlike chroot(), it's not as easy to protect against stuff trying
>> to bypass them while still keeping them useful.
>
> It is the same, you have to be aware of the problem and need to mitigate
> it.
>
> chroot addresses different thinks than capabilities. And also chroot is
> exploitable and you can break out in some cases. You have to do it
> right...
Again, this depends, there really isn't any way to make it impossible to 
break out of a chroot without significant changes to the kernel, even 
when using stuff like namespaces.
>
>> If you do a web search you can relatively easily find info on how to
>> use many of the defined capabilities to get root-equivalent access
>> (CAP_SYS_ADMIN and CAP_SYS_MODULE are obvious, but many of the others
>> can be used also if you know what you are doing, for example
>> CAP_DAC_OVERRIDE+CAP_SYS_BOOT can be used on non-SecureBoot systems to
>> force the system to reboot into an arbitrary kernel).
>
> Well, that is like it should be. If you give an exploitable application
> rights that it should not have, it can get exploited. But this decision
> is in the responsibility of the admin.
The big problem here is stuff like CAP_SYS_ADMIN and CAP_NET_ADMIN, 
which group together a bunch of things that are only loosely related. 
For example, both CAP_NET_ADMIN and CAP_NET_RAW include the ability to 
bind to non-local addresses, but none of the stuff that I've ever seen 
that uses CAP_NET_RAW instead of running as root uses that at all. 
CAP_SYS_ADMIN includes a list of 24 different things that it allows, 
many of which are themselves lists of other operations.
I'll try and dig up one of the better articles on this and post a link, 
essentially, there are about a dozen capabilities that can be exploited 
pretty easily to get root-equivalent access.
>
> With ambient capabilities, you transfer that responsibilities to all the
> different developers that once in a while wrote a SUID tool (or tool
> with raised capabilities). So, tell me, where does the ambient
> capabilities raise the security?
Unless you're personally auditing every single piece of code being run 
on your system, you are inherently trusting the developers anyway.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]