From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967032AbbBDRev (ORCPT ); Wed, 4 Feb 2015 12:34:51 -0500 Received: from h2.hallyn.com ([78.46.35.8]:35248 "EHLO h2.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752929AbbBDRet (ORCPT ); Wed, 4 Feb 2015 12:34:49 -0500 Date: Wed, 4 Feb 2015 18:34:47 +0100 From: "Serge E. Hallyn" To: "Andrew G. Morgan" Cc: Andy Lutomirski , "Serge E. Hallyn" , Christoph Lameter , Serge Hallyn , Serge Hallyn , Jonathan Corbet , Aaron Jones , "Ted Ts'o" , LSM List , lkml , Andrew Morton Subject: Re: [capabilities] Allow normal inheritance for a configurable set of capabilities Message-ID: <20150204173447.GA18361@mail.hallyn.com> References: <20150203155544.GE2923@mail.hallyn.com> <20150203172653.GB4748@mail.hallyn.com> <20150204155617.GE16726@mail.hallyn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ok this is all sounding too magic for my tastes. My original suggestion was for an actual new capability set, pA, empty by default. You can add bits to it using prctl if ns_capable(CAP_SETPCAP) and all the new bits are in your pE. Once set, they stay until they are removed using prctl. At exec, pA' = pA, and fI |= pA (after reading fI from disk but before calculating pI'). Quoting Andrew G. Morgan (morgan@kernel.org): > If permitted is zero (ie., no file capabilities) then I don't think > this will yield any privilege for such an exec. Perhaps I missed > something prior to being included in the thread, but I was under the > impression that this was a case where it was intended that > capabilities would be inherited..? > > If you force pE' too, then this looks more like a mini-root > inheritance which gets me closer to disliking this: you need to > consider that we dangerously close to returning to situations like the > one discussed here: > https://sites.google.com/site/fullycapable/Home/thesendmailcapabilitiesissue > > Cheers > > Andrew > > > On Wed, Feb 4, 2015 at 8:34 AM, Andy Lutomirski wrote: > > On Wed, Feb 4, 2015 at 8:12 AM, Andrew G. Morgan wrote: > >> I was thinking more like this: > >> > >> int override = secure(SECURE_AMBIENT_PRIVS) && > >> cap_isclear(caps->inheritable.cap); > >> > >> CAP_FOR_EACH_U32(i) { > >> __u32 permitted = caps->permitted.cap[i]; > >> __u32 inheritable = override ? new->cap_bset.cap[i] : > >> caps->inheritable.cap[i]; > >> [...] > > > > To elaborate on my objection: > > > > For better or for worse, as a practical matter, if you drop a cap from > > pP but keep it in pI, there's no way to get that cap back on the > > average system to get that cap back using execve because nothing will > > have that bit set in fI. I am not at all confident that changing this > > is safe at this point, since there's lots of legacy code out there. > > > > So, how about: > > > > __u32 inheritable = override ? (new->cap_bset.cap[i] & permitted) : > > caps->inheritable.cap[i]; > > > > instead? > > > > This still doesn't address the effective set adequately, I think. I > > suspect that we'll want to always start with pE' == pP' in the new > > mode, or perhaps pE' = (pP' & pE). This latter part is also a bit > > dangerous and furthers my desire to restrict this to no_new_privs. > > > > --Andy