From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934147AbbBDPPh (ORCPT ); Wed, 4 Feb 2015 10:15:37 -0500 Received: from mail-yk0-f174.google.com ([209.85.160.174]:34965 "EHLO mail-yk0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933635AbbBDPPc (ORCPT ); Wed, 4 Feb 2015 10:15:32 -0500 MIME-Version: 1.0 In-Reply-To: <20150203172653.GB4748@mail.hallyn.com> References: <20150202171257.GD24351@ubuntumail> <20150203155544.GE2923@mail.hallyn.com> <20150203172653.GB4748@mail.hallyn.com> Date: Wed, 4 Feb 2015 07:15:30 -0800 X-Google-Sender-Auth: z9049NrEdUvgugvuZcZnOTF38Ko Message-ID: Subject: Re: [capabilities] Allow normal inheritance for a configurable set of capabilities From: "Andrew G. Morgan" To: "Serge E. Hallyn" Cc: Christoph Lameter , Serge Hallyn , Serge Hallyn , Andy Lutomirski , Jonathan Corbet , Aaron Jones , "Ted Ts'o" , linux-security-module@vger.kernel.org, lkml , akpm@linuxfoundation.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I'm not generally in favor of this. Mostly because this seems to be a mini-root kind of inheritance that propagates privilege to binaries that aren't prepared for privilege. I don't really buy the mmap code concern because the model as it stands says that you trust the binary (and all of the various ways it was programmed to execute code) with specific privileges. If the binary mmap's some code (PAM modules come to mind) then that is part of what it was programmed to/allowed to do. That being said, if you really really want this kind of thing, then make it a single secure bit (with another lock on/off bit) which, when set, makes: fI default to X. pP' = (X & fP) | (pI & fI) That way the per-process bounding set still works as advertised and you don't need to worry about the existing semantics being violated. Cheers Andrew On Tue, Feb 3, 2015 at 9:26 AM, Serge E. Hallyn wrote: > Quoting Christoph Lameter (cl@linux.com): >> On Tue, 3 Feb 2015, Serge E. Hallyn wrote: >> >> > We've currently got two proposals. (Three includig yours; but I explained my >> > problem with yours earlier this morning - do appreciate the proposal and >> > the patch though, really, thanks) It's worth digging into the details of >> > each, but if they end up complicating things then perhaps "dropping >> > capabilities and going with something new" ought to be another proposal. >> >> Ok that is about the binding to a person and executable? > > It's about at least making it per-process(-tree). > >> So you think there should be a cap_inheritable mask settable in the caps >> of each file. > > No. I mean, we have that now. I just want to require a privileged process > to fill in the pA in the first place. If people are currently using file > caps "as intended" I don't want behavior to change for them.