Re: [PATCH 5/9] Make use of permissions, returned by kobj_lookup

[Serge E. Hallyn]

Quoting Greg KH (greg@xxxxxxxxx):
> On Fri, Mar 07, 2008 at 11:35:42AM -0600, Serge E. Hallyn wrote:
> > > Do you really want to run other LSMs within a containerd kernel?  Is
> > > that a requirement?  It would seem to run counter to the main goal of
> > > containers to me.
> > 
> > Until user namespaces are complete, selinux seems the only good solution
> > to offer isolation.
> 
> Great, use that instead :)

That can't work as is since you can't specify major:minor in policy.
So all we could do again is simply refuse all mknod, which we can
already do with per-process capability bounding sets.

> > > > 2. Turning CONFIG_SECURITY on immediately causes all the other hooks
> > > >    to get called. This affects performance on critical paths, like
> > > >    process creation/destruction, network flow and so on. This impact
> > > >    is small, but noticeable;
> > > 
> > > The last time this was brought up, it was not noticable, except for some
> > > network paths.  And even then, the number was lost in the noise from
> > > what I saw.  I think with a containered machine, you have bigger things
> > > to be worried about :)
> > > 
> > > > 3. With LSM turned on we'll have to "virtualize" it, i.e. make its
> > > >    work safe in a container. I don't presume to judge how much work
> > > >    will have to be done in this area, so the result patch would be
> > > >    even larger and maybe will duplicate functionality, which is currently
> > > >    in cgroups. OTOH, cgroups already provide the ways to correctly 
> > > >    delegate proper rights to containers.
> > > 
> > > No, your lsm would be your "virtualize" policy.  I don't think you would
> > > have to do any additional work here, but could be wrong.  Would like to
> > > see the code to prove it.
> > > 
> > > > > Opening a dev node is not on any "fast path" that you need to be
> > > > > concerned about a few extra calls within the kernel.
> > > > > 
> > > > > And, I think in the end your patch would be much smaller and easier to
> > > > > understand and review and maintain overall.
> > > > 
> > > > Hardly - the largest part of my patch is cgroup manipulations. The part
> > > > that makes the char and block layers switch to new map ac check the 
> > > > permissions is 10-20 lines of new code.
> > > > 
> > > > But with LSM I will still need this API.
> > > 
> > > Yes, but your LSM hooks will be smaller than the code modifications to
> > > the map logic :)
> > > 
> > > Again, I object to this as you are driving a new security policy
> > > infrastructure into the device node logic where it does not belong as we
> > > already have this functionality in the LSM interface today.  Please use
> > > that one instead and don't clutter up the kernel with "one-off" security
> > > changes like this one.
> > > 
> > > Please try the LSM interface and see what happens.  If, after you have
> > 
> > https://lists.linux-foundation.org/pipermail/containers/2007-November/008589.html
> > 
> > This was just a proof of concept for discussion.
> 
> I don't see the LSM patch in that posting, only a Makefile change that
> adds it to the build.

Aw, crap!  That's right, I remember noticing a few days later that it
wasn't in my git index any more.

An older version (by about a month) of the patch with the LSM coded
straight into the cgroup file is appended below.

> > Our conclusion (including my own) was that it would be nicer to have the
> > controls not be shoed in using lsm but rather at the level Pavel was
> > doing.
> 
> Why?  What is the difference?  I don't see that discussion anywhere in
> that post.

That happened in a later thread in december:
https://lists.linux-foundation.org/pipermail/containers/2007-December/009337.html

> Why add add-hock security stuff to the kernel all over the place and not
> use the LSM interface that we already have?  If LSM doesn't provide the
> exact right hooks needed, we can always change it (and no, we should not
> be adding kobj_maps hooks to LSM).
> 
> thanks,
> 
> greg k-h