Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966856AbbBDQyl (ORCPT ); Wed, 4 Feb 2015 11:54:41 -0500 Received: from mail-yk0-f174.google.com ([209.85.160.174]:43277 "EHLO mail-yk0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966108AbbBDQyi (ORCPT ); Wed, 4 Feb 2015 11:54:38 -0500 MIME-Version: 1.0 In-Reply-To: References: <20150202171257.GD24351@ubuntumail> <20150203155544.GE2923@mail.hallyn.com> <20150203172653.GB4748@mail.hallyn.com> <20150204155617.GE16726@mail.hallyn.com> Date: Wed, 4 Feb 2015 08:54:37 -0800 X-Google-Sender-Auth: olTXEGB2lwu4MuVNsTpENfa3MLw Message-ID: Subject: Re: [capabilities] Allow normal inheritance for a configurable set of capabilities From: "Andrew G. Morgan" To: Andy Lutomirski Cc: "Serge E. Hallyn" , Christoph Lameter , Serge Hallyn , Serge Hallyn , Jonathan Corbet , Aaron Jones , "Ted Ts'o" , LSM List , lkml , Andrew Morton Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2143 Lines: 56 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 -- 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/