Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752280AbbKKLNr (ORCPT ); Wed, 11 Nov 2015 06:13:47 -0500 Received: from tschil.ethgen.ch ([5.9.7.51]:43364 "EHLO tschil.ethgen.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751508AbbKKLNp (ORCPT ); Wed, 11 Nov 2015 06:13:45 -0500 Date: Wed, 11 Nov 2015 12:13:38 +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] Re: [KERNEL] [PATCH] Kernel 4.3 breaks security in systems using capabilities Message-ID: <20151111111337.GB8272@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: <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> <20151111101433.GA16765@ikki.ethgen.ch> <20151111105441.GA20241@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; x-action=pgp-signed In-Reply-To: <20151111105441.GA20241@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 Content-Length: 4526 Lines: 97 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am Mi den 11. Nov 2015 um 11:54 schrieb Theodore Ts'o: > On Wed, Nov 11, 2015 at 11:14:34AM +0100, Klaus Ethgen wrote: > > > 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..? > > But the developer can also change what files they look at; in fact, > they are *more* likely to make that kind of changes during the normal > course of development; not deliberately or maliciously, but as part of > adding a new feature to their program. If you don't have time to > audit to make sure they aren't using some new capability feature > (which you can do using the simple application of "grep"), you don't > have time to audit to make sure they haven't changed something which > will cause their use of CAP_DAC_OVERRIDE to be dangerous. > > Which is why I maintain it is very wierd that you are paranoid about > the first concern, but are blithely unconcerned about the second, > which is more likely. And it is *because* you are the one who have > this extremely strange and selective paranoia, and most other people > won't, it seems fair (to me) that you are the one that has to pay the > extra cost of working around the problem. After all, if you're this > paranoid, you must building all of your binaries from scratch, too. > > (Or else you have to trust lots of package maintainers or distro > release engineers. All right. The only thing you can do is to do all you can. And lowering SUID use to selective capability use is one important step in that direction. There is no way to have a all secure system. You can only do the most possible. Nevertheless, I object a _new_ feature that brings some security concernes. So it is not uncommon, to work on that. > I'll remind you that some of the more catastrophic > security problems have come from Debian maintainers, some of which > made patches in code they didn't completely understand, and which had > nothing to do with elevated privileges.) Thats true. For example openssh patching debacle just to support some accomodativeness on the cost of security. Upstream refused that patch but they still have it in debian. That was when I did start packaging my own openssh package in my own "debian-security" repository. However, that is a single package (in fact, I have a few there). With every package that has to be fixed the load goes more in the direction of not being capable anymore to handle it. Also that discussion here is, especially from the fact that english is not my main language, time-consuming. But I was thinking (and still hope) that kernel developers are not that stupid than some debian maintainers. I still hope that they are not so stubborn to ignore a use-case that is already used by some out there and only focusing on a use-case that is used nowhere. > So the cost of patching init to set the securebit should be in the > noise for you. As it is to provide a patch that does it right. (As I did already.) 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 iQGcBAEBCgAGBQJWQyLcAAoJEKZ8CrGAGfasSH0L/1NLo4fxZoEL1PNDCKCcmlUW 8h3ThJhdNQqu8xRl47Q6RW/K7tv0My/blihNZEzIn6ssmTXd8JIlP3uHfz+XA2aZ FbduAc2KOoW8H1ItYbWL4hnJq94/Pvp+0vOBMSG+fKL/09A8X8RmiAiCsnX6Eirl 64WCk1dyDILWPpkQ0w7XKy4DA69AX7DSBLpYCANwOsFzIZR0Npx3VinF55kVHE53 9g3x8+NifOLJ3qPkSwUg+U86AOWlQhnsI3EQJYwJ+WLnkrHEoKHvBlDDRqfNMoRK c1IqgD9ISnjPf1PO+MQ2CQ0kE8VdTXNaZKU4PvFFzJJE1iAa2SgJjY/tXLgmHaQ/ RCs6RoJkZ/8VbpmOFcALNJuIIWjaG6GUii296MnvYPE2VnJXQ3NoUDsRlmA5jRBA klmbWAOz5pBknx5AE8zjgAyHQ/trpNxHnW+OBtfhxqoohTIZJxHIDxZD6MuSNVVs dw9MJf/pR6T4xN70H9oFG7eb7Ic3E92IFkSsM9Vvng== =P+pQ -----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/