Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752780AbbKGLC6 (ORCPT ); Sat, 7 Nov 2015 06:02:58 -0500 Received: from tschil.ethgen.ch ([5.9.7.51]:42711 "EHLO tschil.ethgen.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751274AbbKGLC4 (ORCPT ); Sat, 7 Nov 2015 06:02:56 -0500 Date: Sat, 7 Nov 2015 12:02:47 +0100 From: Klaus Ethgen To: "Serge E. Hallyn" Cc: "Theodore Ts'o" , Andy Lutomirski , Linus Torvalds , Richard Weinberger , LKML , Christoph Lameter , Andy Lutomirski , Serge Hallyn , Kees Cook , Andrew Morton Subject: Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities Message-ID: <20151107110246.GA7230@ikki.ethgen.ch> References: <20151105161512.GA2180@mail.hallyn.com> <20151105171701.GB9307@ikki.ethgen.ch> <20151105173438.GA3378@mail.hallyn.com> <20151105174823.GD9307@ikki.ethgen.ch> <20151105220843.GA6027@mail.hallyn.com> <20151106135835.GB11901@ikki.ethgen.ch> <20151106155303.GB6160@thunk.org> <20151106175619.GA19491@ikki.ethgen.ch> <20151106181820.GB16749@mail.hallyn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; x-action=pgp-signed In-Reply-To: <20151106181820.GB16749@mail.hallyn.com> 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: 4054 Lines: 87 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Guys, Am Fr den 6. Nov 2015 um 19:18 schrieb Serge E. Hallyn: > On Fri, Nov 06, 2015 at 06:56:20PM +0100, Klaus Ethgen wrote: > > Am Fr den 6. Nov 2015 um 16:53 schrieb Theodore Ts'o: > > > In the light of that, using things like ambient capabilities, or using > > > setuid binary that immediately drops all caps that it needs, is > > > probably the best we're going to get. > > > > I do never want that! Even to think about such a way to give any shell > > raised rights is horrible! And that horrible idea is it that makes all > > the ambient capabilities that bad. > > I sympathize with your point of view, but Christoph's use case really was > a good one. I don't think so. Read on... > A piece of system configuration software needs to do some > networking setup with some privilege, including calling scripts. It can > either do so as root or not at all - polluting every program that will end > up getting called with fI is not only ugly but simply doesn't work (because > scripts). Saying that the whole thing must be written as self-contained > executable that never needs to be re-execed is frequently unrealistic. > So this allows a piece of software to run with reduce privilege, and it > is an improvement over the previous state of affairs. Having some scripts in the process is definitively a nightmare to control. That should be prevented wherever possible. And usually it is as the scripts might be used for computing some values that are used later in privileged stuff. However, that usecase has one more flaw I think. It is the human nature. Someone that create a tool made for running as root or especially SUID is usually careful to do so. If they know right now that the tool is never run as root, then they don't care about many thinks that needs to get addressed for root stuff. Good example are all that userspace python tools that throw all that stack traces around the users ears (I don't know if that saying exists in English...) instead of giving proper error messages. > I would have been happy if there had been a default-off PR_ENABLE_AMBIENT > prctl which required a new CAP_ENABLE_AMBIENT capability to turn on, but > the current set of rules which removes bits from pA whenever doing an > action which capability-aware software does something which it would have > reasonably expected to drop privilege is a nice safeguard. Well, not really. You can only prevent ambient capabilities to be given to tools you don't want to have any capabilities by setting that tool SUID or setting just one random capability for it. By the way, guys, can we start to _not_ add every one in this discussion to the Cc? Currently I get every mail twice. One from the list and one from Cc. I still leave all Ccs intact with this mail but I would prefer to just reply to the list. If anybody is not reading the list and would like to get the mail, please insist. 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 iQGcBAEBCgAGBQJWPdpRAAoJEKZ8CrGAGfasAaUL/jLZg82kUfL5ByyZ5bUINxvY kTRIaUTkgSRwkMQF5p+ILkVajE/YVAfD4MZFdZrB62PNbhvvCdy4R9jefVPcBlae CTJuaDguWr2UZvPX6C25l2Q/ix2v9K2zOlgbhf23piXisfdLD3b1i6YlpYAJ4MRU gakxTWylYCUhIt2j6dzlxPGN691o3q59kLa+1wCBXcMXr4gB8i93NjAloS6/ud+/ tC+6Ld+tbJFjoG/3HJ6qBCabaz41HVFnSPPQBohv19lSM1oDjUvH6wO9QGHBxYNN S8IrBPrsINjm2l4kbNqUexIA+GGn7uPYO1SLjWl/VxfiegT5DfwArYakzsSnpQS/ Y30RlKJHSwl+nP/dxxN2kaqmrrmppcvh0HemKvnJX75UwZ/ROw7ACVCcGZQIqlUs FssHB/lw48fhMQ5/WYjVRXBIQdbN1tmj9s6r22Vwez4sNst2ak4F+zO7NLwuYwmY AstL8IyovKSHT52jsASydFBZ4PpG2PsPkZIRIUTLDQ== =5Iab -----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/