Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754523AbbKBSim (ORCPT ); Mon, 2 Nov 2015 13:38:42 -0500 Received: from mail-oi0-f53.google.com ([209.85.218.53]:32801 "EHLO mail-oi0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753075AbbKBSil (ORCPT ); Mon, 2 Nov 2015 13:38:41 -0500 MIME-Version: 1.0 In-Reply-To: <20151102180624.GA28014@ikki.ethgen.ch> References: <20151102180624.GA28014@ikki.ethgen.ch> Date: Mon, 2 Nov 2015 19:38:40 +0100 Message-ID: Subject: Re: Kernel 4.3 breaks security in systems using capabilities From: Richard Weinberger To: Klaus Ethgen Cc: 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 Content-Length: 3703 Lines: 84 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. > > 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. > > So please revert that patch as fast as possible before it does some harm > by getting into some real world systems! > > Regards > Klaus Ethgen > - -- > Klaus Ethgen http://www.ethgen.ch/ > pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen > Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQGcBAEBCgAGBQJWN6YaAAoJEKZ8CrGAGfasRGwL/2g3XmG3h1rpidmJnUsMlmvf > YdBSSKdgX8U371WANxoGPzmjE9raQX+Ccn713z8csB/Xnh3AuQMvDsRfX9qWhYCy > eDEE3NxaDvlKzZkDDvZk5TFuFI8iHBIndgkYdN6AYg60aUt9GRYEVIZ9AtZ0t2LG > /x9v7ecF0BEmJRK/Hf6uBfmGsh1sisyJzDtkvh4z/P6RUh/96W0sMZTi0MGolfvT > 6B8WPWnyOVRHmxwq1/2rExOr4rwyiDhOc+oGHzj+XfIh30pXUZnlom7w0M5cro61 > jK/bJbCQJdqgADp3Nuizf6WUCt/adKqwmlAmKD2kFSFOtUG0A32jdhcqLKBO5aWX > 5Cm2lub5a7mdM1hSRGDKzmrQ4phQZNqGUHXG2TOiit5IbmcA0AEyy091oB15Rf6x > xnOoe7nIIPsoDlbfMoQq7qPvbIB4gXimoJtKI4+T4AKr068XWfXeswAYc8V1yviJ > o4R6ja52HwEZ/PykLJFmtiEcfYDQQeT2eADj0kN7rQ== > =m53H > -----END PGP SIGNATURE----- > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/