From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932585AbbBDC1h (ORCPT ); Tue, 3 Feb 2015 21:27:37 -0500 Received: from resqmta-ch2-02v.sys.comcast.net ([69.252.207.34]:53907 "EHLO resqmta-ch2-02v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932142AbbBDC1f (ORCPT ); Tue, 3 Feb 2015 21:27:35 -0500 Date: Tue, 3 Feb 2015 20:27:32 -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 On Tue, 3 Feb 2015, Andy Lutomirski wrote: > >> 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. You should get it back because there may be executables invoked by that binary that need it. > > 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? Hmmmm... Ok did not think about that so far. > >> 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. Well then its no longer an optin but automatic. Sure that would work. The patch also should not be too difficult to do.