Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754512AbbKBSGb (ORCPT ); Mon, 2 Nov 2015 13:06:31 -0500 Received: from tschil.ethgen.ch ([5.9.7.51]:46908 "EHLO tschil.ethgen.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754491AbbKBSG3 (ORCPT ); Mon, 2 Nov 2015 13:06:29 -0500 Date: Mon, 2 Nov 2015 19:06:25 +0100 From: Klaus Ethgen To: linux-kernel@vger.kernel.org Subject: Kernel 4.3 breaks security in systems using capabilities Message-ID: <20151102180624.GA28014@ikki.ethgen.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; x-action=pgp-signed OpenPGP: id=79D0B06F4E20AF1C; url=http://www.ethgen.ch/~klaus/79D0B06F4E20AF1C.txt; preference=signencrypt User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3209 Lines: 70 -----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/