Re: [PATCH 0/3] Taming execve, setuid, and LSMs

["Serge E. Hallyn" <serue@us.ibm.com>]

Quoting Andrew Lutomirski (luto@mit.edu):
> On Mon, Apr 19, 2010 at 5:39 PM, Serge E. Hallyn <serge@hallyn.com> 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