Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754000AbbBCXOK (ORCPT ); Tue, 3 Feb 2015 18:14:10 -0500 Received: from resqmta-ch2-11v.sys.comcast.net ([69.252.207.43]:56546 "EHLO resqmta-ch2-11v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751403AbbBCXOG (ORCPT ); Tue, 3 Feb 2015 18:14:06 -0500 Date: Tue, 3 Feb 2015 17:14:04 -0600 (CST) From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Andy Lutomirski 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 Subject: Re: [capabilities] Allow normal inheritance for a configurable set of capabilities In-Reply-To: Message-ID: 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> Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2560 Lines: 59 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. > 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. > 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 ? -- 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/