[systemd-devel] [PATCH 2/2] Run with a custom SMACK domain (label).

[Schaufler, Casey]

> -----Original Message-----
> From: Lennart Poettering [mailto:lennart at poettering.net]
> Sent: Thursday, October 10, 2013 9:51 AM
> To: Schaufler, Casey
> Cc: Kok, Auke-jan H; Zbigniew Jędrzejewski-Szmek; systemd-devel
> Subject: Re: [systemd-devel] [PATCH 2/2] Run with a custom SMACK domain
> (label).
> 
> On Tue, 08.10.13 22:29, Schaufler, Casey (casey.schaufler at intel.com) wrote:
> 
> > > On Mon, 07.10.13 10:30, Kok, Auke-jan H (auke-jan.h.kok at intel.com)
> wrote:
> > >
> > > > > Hi,
> > > > > the patches look OK. I dont' have a system with smack support at
> > > > > hand, but I tested them on Fedora, and didn't notice any adverse
> effects.
> > > > > I you've tested them with smack, then they should be applied, imo.
> > > >
> > > > Thanks, I just applied them myself - I just wanted to give folks a
> > > > bit of time to read and test - so thanks for doing so!
> > >
> > > Hmm, the patches as they are merged now try to mount the SMACK
> > > version of /run and /dev/shm also in containers. Will this work?
> >
> > So long as the cgroup filesystem propagates the xattrs to and from the
> > real filesystem it won't be a problem. If the cgroup filesystem is not
> > doing that there will be a problem.
> 
> I can't parse this.

That's because it doesn't make sense.
I had been under the impression that cgroupfs was something
other than what it is. Now that I understand better I see that
this is a nonsensical statement.

Read it as "everything is OK".
 
> > > So far (at least for SELinux) we tried to turn off all security
> > > layers in containers, since the policies are not virtualized.
> >
> > I don't know what you mean by "virtualized" in this context.
> 
> Well, unlike for example the PID namespace stuff where the PIDs are
> virtualized there is no scheme where the SMACK enforcement could be
> virtualized, so that an OS container could install its own SMACK policy, and so
> that SMACK labels from the container are different things even though they
> share the same name with labels from the host. (I mean, I am not saying this
> would be even desirable...)

OK, that 

We've identified how we could do Smack namespaces if we wanted
to. I am pretty sure that we don't want to at this point, and that
we probably won't in the near future.

> 
> Lennart
> 
> --
> Lennart Poettering - Red Hat, Inc.