From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752512AbbKKKOo (ORCPT ); Wed, 11 Nov 2015 05:14:44 -0500 Received: from tschil.ethgen.ch ([5.9.7.51]:43049 "EHLO tschil.ethgen.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752110AbbKKKOm (ORCPT ); Wed, 11 Nov 2015 05:14:42 -0500 Date: Wed, 11 Nov 2015 11:14:34 +0100 From: Klaus Ethgen To: "Theodore Ts'o" , Andy Lutomirski , Serge Hallyn , Kees Cook , Christoph Lameter , "Serge E. Hallyn" , Andrew Morton , Richard Weinberger , Austin S Hemmelgarn , LKML , Linus Torvalds Subject: Re: [KERNEL] Re: [KERNEL] [PATCH] Kernel 4.3 breaks security in systems using capabilities Message-ID: <20151111101433.GA16765@ikki.ethgen.ch> Mail-Followup-To: Theodore Ts'o , Andy Lutomirski , Serge Hallyn , Kees Cook , Christoph Lameter , "Serge E. Hallyn" , Andrew Morton , Richard Weinberger , Austin S Hemmelgarn , LKML , Linus Torvalds References: <20151107110246.GA7230@ikki.ethgen.ch> <5640C999.5050807@gmail.com> <20151109172340.GF3714@ikki.ethgen.ch> <5640EDB4.70407@gmail.com> <20151109212937.GA17624@ikki.ethgen.ch> <20151110115526.GA2958@ikki.ethgen.ch> <20151110124043.GC3717@thunk.org> <20151110131907.GB2958@ikki.ethgen.ch> <20151111020420.GD3717@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; x-action=pgp-signed In-Reply-To: <20151111020420.GD3717@thunk.org> 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am Mi den 11. Nov 2015 um 3:04 schrieb Theodore Ts'o: > On Tue, Nov 10, 2015 at 02:19:08PM +0100, Klaus Ethgen wrote: > > > And that's the fundamenal problem. Saying that you can only be secure > > > if **no** scripting languages can be used for **any** privileged > > > operations is something that _might_ work for you, but it doesn't work > > > for the 99.99999999999% of the Linux systems out there, many of which > > > have shell scripts to configure networking, or any host of other > > > things. Arguably, it's why Posix capalities have utterly failed as > > > far as usage except for a very, very, very, tiny, limited market. > > > > But this is use case 1 of two that I described earlier. And this is the > > main use case that is addressed by the ambient capabilities. I'm fine > > with that. That is nothing that I would object. > > Actually, you did. To quote from an earlier message, "I would not > only say that it [administrative shell scripts running with privilege] > is avoidable, it is the worst that can happen." That's a pretty > strong objection in my book. And it's why discussing thing with you > is a bit frustrating. Sorry, that I was misleading. I always told that in context of second usecase. In the first usecase that is about reducing capabilities instead of raising them, shells are already meant and used with all rights. The problem with shell scripts only (mostly) arise in the second usecase. I still keep my speaking that I will not object the first usecase. > > What I want to get fixed is the second use case of capabilities that was > > completely ignored by the design of ambient capabilities. It is about > > _raising_ explicitly single capabilities for _unprivileged_ > > binaries/users. > > That works fine with ambient capabilities. You can raise a single > capability with an unprivileged executable without any problems. The > problem is that you seem willing to trust that executable to have the > capability via an fscap setting, and not misuse it. *But* at the same > time you don't trust that executable to take an explicit set to allow > any of its children to use that executable. Yes. > That's a wierd thing to both simultaneously trust and distrust. Particular, I trust nobody (not even myself sometimes). But giving privileges is needed for some tasks. Ambient capabilities raise that to a new level. > After all, suppose you give some process CAP_DAC_OVERRIDE, so it can > read any file on the system. Particular, I would only give that capability (as the others) in exchange to being SUID. > How can you trust that it won't do > anything bad with that power? The only way you can do that is by > carefully auditing the code to make sure it won't do anything untoward > with that bit (either deliberately/maliciously or due to some > programming bug). Right. I do that from time to time. But unfortunately my time is limited. So keep in mind, I use capabilities to _limit_ rights to the lowest set that former had have SUID bit set. > If you are going to do that level of auditing, then > you can also check to make sure it's not trying to explicitly > manipulate the processes's capability mask to set the bit in the > ambient capability mask (which is just another malicious use of the > capability). Well, you audit one version. What if the developer sees: "Oh, there is one new shiny thing in kernel, called ambient capabilities. Lets set them to all my capabilities. That looks great", after you audited the code..? > Arguably, auditing this is much *less* effort than > making sure that the process isn't going to abuse CAP_DAC_OVERRIDE. No, auditing is hard work. And I simply have not the manpower to do it for every tool for every new version. As I believe, nobody has. > As far as complaint that you can't set securebits for the entire > system, sure you can. Just move /sbin/init to /sbin/init.real, and > replace /sbin/init with a program which sets > SECURE_NO_CAP_AMBIENT_RAISE and SECURE_NO_CAP_AMBIENT_RAISE_LOCKED, > and then exec's /sbin/init.real. Done! No kernel patch needed. :-) Yea, that could work. But it is far more hacky than doing it right in the kernel. However, a kernel patch brought in that, in my eyes, security mess. There was already an additional patch on request of Andrew Morgan. I believe he had good reasons for asking for this. However, I don't see where my objection is less serious than his apart the fact that he is a well known kernel hacker and I am just a paranoid nobody. Regards Klaus - -- 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 iQGcBAEBCgAGBQJWQxUEAAoJEKZ8CrGAGfasUtsL/jehWjS5u4IAUlOSGcoEM3zl OJjA+Ez9CE6TGykkAwhJLlP3zmUsI/hn+09XNqSHFtezfycmp7tjRjWIsiNvb42Z cMTpkUryBPpnOgrdZlr+YxmCyzO4jQs/5qly/MKBiR67GhquS0jlLKOWWRRT1Nkv SpT8zEuGKB0O1SKY3FTKgSyxARA5eBNB4dqKYc7EFBYCWdPtYlOnDOMet+07dJp5 v7Acn506V0n30TztMQBIFovoX14yyT7nz/v3Td6yk6M7TxL8HXm2G4dDc2w/wPD7 msLEPTOS+WZ/M7DrYS8jIYwPGmW7as7FuOcPtjicGK9YBppEQJSygRHivxtUsD2b TRrdD1TyPenPOWERg2DmbpHMyOyaydH09ZbE1EaMxYwW4yVHVUo5oMsjzQZNjvEJ vv1ciZygaQe7c5uzVyMyHmrmuwtJn70tuPGB0boO4JnZgL6AvyVCqNyQ9aMU5OKc OFvFdHxWnqiXHPjgBapevHVgUPKtTPV7q7vgUUyj7w== =nf3o -----END PGP SIGNATURE-----