Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752821Ab0DSWZS (ORCPT ); Mon, 19 Apr 2010 18:25:18 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]:49926 "EHLO e32.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752716Ab0DSWZP (ORCPT ); Mon, 19 Apr 2010 18:25:15 -0400 Date: Mon, 19 Apr 2010 17:25:13 -0500 From: "Serge E. Hallyn" To: Andrew Lutomirski Cc: linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, Eric Biederman , "Andrew G. Morgan" Subject: Re: [PATCH 0/3] Taming execve, setuid, and LSMs Message-ID: <20100419222513.GA25851@us.ibm.com> References: <20100419172639.GA15800@us.ibm.com> <20100419213952.GA28494@hallyn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1752 Lines: 36 Quoting Andrew Lutomirski (luto@mit.edu): > On Mon, Apr 19, 2010 at 5:39 PM, Serge E. Hallyn wrote: > > Quoting Andrew Lutomirski (luto@mit.edu): > >> > > >> > ( I did like using new securebits as in [2], but I prefer the > >> > automatic not-raising-privs of [1] to simply -EPERM on uid/gid > >> > change and lack kof checking for privs raising of [2]. ) > >> > > >> > Really the trick will be finding a balance to satisfy those wanting > >> > this as a separate LSM, without traipsing into LSM stacking territory. > >> > >> I think that making this an LSM is absurd. ?Containers (and anything > >> else people want to do with namespaces or with other new features that > >> interact badly with setuid) are features that people should be able to > > > > Yes, but that's a reason to aim for targeted caps. ?Exec_nopriv or > > whatever is more a sandbox than a namespace feature. > > > >> use easily, and system's choice of LSM shouldn't have anything to do > >> with them. ?Not to mention that we're trying to *add* rights (e.g. > >> unprivileged unshare), and LSM is about *removing* rights. > > Is a targeted cap something like "process A can call setdomainname, > but only on one particular UTS namespace?" Right, only to the UTS ns in which you live. See for instance http://thread.gmane.org/gmane.linux.kernel.containers/15934 . It's how we express for instance that root in a child user_namespace has CAP_DAC_OVERRIDE over files in the container, but not over the host. -serge -- 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/