linux-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: <CALCETrUaCntyegj7JPqo4V5Rbx1WXKw9PQ7dizUQhbNvnbcOBQ@mail.gmail.com>
Date:	Mon, 2 Nov 2015 10:50:16 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Richard Weinberger <richard.weinberger@...il.com>
Cc:	Klaus Ethgen <Klaus+lkml@...gen.de>,
	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>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Kernel 4.3 breaks security in systems using capabilities

On Mon, Nov 2, 2015 at 10:38 AM, Richard Weinberger
<richard.weinberger@...il.com> wrote:
> CC'ing patch authors.
>
> On Mon, Nov 2, 2015 at 7:06 PM, Klaus Ethgen <Klaus+lkml@...gen.de> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> Hi,
>>
>> I read recently about patch 58319057b7847667f0c9585b9de0e8932b0fdb08
>> which made it into kernel 4.3 recently. And I have to say that I was
>> shocked on how could such a patch that breaks normal use of capabilities
>> make it into the kernel.
>>
>> Usually I have set very own crafted capabilities set to files instead of
>> having them SUID root. With that, I have a comparable set of inheritable
>> capabilities set for limited users. That allows me to nearly drop all
>> SUID binaries and replace it by only giving the processes the
>> capabilities they need but only if the users are allowed to act with
>> that capabilities. Especially, and that is important, it inhibit any
>> leak of rights to any forked process, be it indented or by a security
>> problem of the binary.
>>
>> With the patch above, any process that is spawned by such a program will
>> inherit the raised capabilities if it has no own filecapabilities set.
>> Even worse, even every user made tool can be target for such
>> escalations! That drives the benefits in security of capabilities over
>> SUID ad-absurdum.

Can you describe what it is that you think changed in 4.3 that breaks
anything?  The behavior of inheritable capabilities shouldn't have
changed.

>>
>> Let me add here, that I disagree with Andy Lutomirski about the
>> usefulness of capability inheritance in kernels before that patch. They
>> was fully usefull to only allow selective capabilities if both, the
>> binary and the user was allowed to use it. I never want to have any
>> capabilities for processes that I did not allow them to have. Even
>> worse, I never want any capabilities allowed for any shell. It is
>> horrible to even think about such a possibility!.
>>
>>> Users with nonzero pA are unlikely to unintentionally leak that
>>> capability. If they run programs that try to drop privileges, dropping
>>> privileges will still work.
>>
>> Even that is naiv. There are only few programs out there that do
>> actively drop privileges. Most are agnostic about capabilities. But this
>> crappy patch introduce a need for _every_ tool to drop all capabilities
>> right after start to stay in a secure system.
>>

I don't know what you mean.  Concrete examples are welcome.

--Andy
--
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/