From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754374AbbKBSui (ORCPT ); Mon, 2 Nov 2015 13:50:38 -0500 Received: from mail-ob0-f171.google.com ([209.85.214.171]:35118 "EHLO mail-ob0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752821AbbKBSuh (ORCPT ); Mon, 2 Nov 2015 13:50:37 -0500 MIME-Version: 1.0 In-Reply-To: References: <20151102180624.GA28014@ikki.ethgen.ch> From: Andy Lutomirski Date: Mon, 2 Nov 2015 10:50:16 -0800 Message-ID: Subject: Re: Kernel 4.3 breaks security in systems using capabilities To: Richard Weinberger Cc: Klaus Ethgen , LKML , Christoph Lameter , Andy Lutomirski , Serge Hallyn , Kees Cook , Andrew Morton , Linus Torvalds Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 2, 2015 at 10:38 AM, Richard Weinberger wrote: > CC'ing patch authors. > > On Mon, Nov 2, 2015 at 7:06 PM, Klaus Ethgen 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