Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932538AbbBCXSL (ORCPT ); Tue, 3 Feb 2015 18:18:11 -0500 Received: from mail-lb0-f170.google.com ([209.85.217.170]:38400 "EHLO mail-lb0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754137AbbBCXSG (ORCPT ); Tue, 3 Feb 2015 18:18:06 -0500 MIME-Version: 1.0 In-Reply-To: References: <54CFB9B8.8020701@schaufler-ca.com> <20150202180806.GE24351@ubuntumail> <54CFE3E8.2030402@schaufler-ca.com> <20150203155122.GD2923@mail.hallyn.com> <54D0F94D.3050704@schaufler-ca.com> <20150203172837.GC4748@mail.hallyn.com> <54D10A50.5030707@schaufler-ca.com> From: Andy Lutomirski Date: Tue, 3 Feb 2015 15:17:44 -0800 Message-ID: Subject: Re: [capabilities] Allow normal inheritance for a configurable set of capabilities To: Christoph Lameter Cc: Casey Schaufler , "Serge E. Hallyn" , Serge Hallyn , Serge Hallyn , Jonathan Corbet , Aaron Jones , "Ted Ts'o" , LSM List , "linux-kernel@vger.kernel.org" , 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: 3270 Lines: 81 On Tue, Feb 3, 2015 at 3:14 PM, Christoph Lameter wrote: > On Tue, 3 Feb 2015, Andy Lutomirski wrote: > >> > */ >> > new->cap_permitted.cap[i] = >> > (new->cap_bset.cap[i] & permitted) | >> > - (new->cap_inheritable.cap[i] & inheritable); >> > + (new->cap_inheritable.cap[i] & inheritable) | >> > + (ambient & inheritable); >> >> Is there a clear reason why no non-permitted bits can be inheritable? >> If not, then I think this should be (ambient & inheritable & >> permitted). > > Inherited caps via ambient are always be permitted. Otherwise the pass > through is not working. Sure, but what about inheritable caps before exec? Suppose I drop some cap from the permitted set but leave it in the inheritable set. I shouldn't get it back by calling execve. > >> Do we need to think about the effective mask here? What happens when >> we exec a setuid program or a program with a non-empty fP set? I >> think that, in these cases, we should strongly consider clearing the >> ambient set. For a different approach, see below. >> >> > >> > if (permitted & ~new->cap_permitted.cap[i]) >> > /* insufficient to execute correctly */ >> > ret = -EPERM; >> > + >> > + if (capable(CAP_AMBIENT_MASK)) >> > + new->cap_ambient.cap[i] = inheritable; >> > + else >> > + new->cap_ambient.cap[i] = ambient; >> >> IMO this is really weird. I don't think that the presence of an >> effective cap should change the cap equations. (Also, that should be >> nsown_capable.) > > Well how would the ambient mask to be set? The other options are adding a > new syscall and having to go through an interation of the capabilities > tools and/or kernel syscall API changes. prctl? > >> Can we please make this an explicit opt-in? For example, allow a >> process to set an ambient cap bit if that bit is both permitted and >> inheritable. I'd prefer having it be a single control, though -- just >> prctl(PR_SET_ALWAYS_INHERIT_CAPS, 1, 0, 0, 0) would set a single bit >> that would cause all inheritable bits to be treated as ambient. > > Opt-in does not work since the caps need to be passed > through binaries that do not use the capabilities. > >> Here's a slight variant that might be more clearly safe: add an >> inherited per-process bit that causes all files to act as though fI is >> the full set. Only allow setting that bit if no_new_privs is set. > > CAP_INHERIT_ALL ? > Sure. Would this approach work for your use case? It would work for mine, and it avoids needing to think about how this new kind of inheritance would interact with setuid, setgid, and file caps (i.e. it wouldn't, because you have to turn on off to get the other). Opt-in should work fine as long as the opt-in is inherited. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- 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/