container/container-medium-19.ks container/container-medium-20.ks container/container-minimal-19.ks container/container-minimal-20.ks

Daniel J Walsh dwalsh at
Thu Sep 19 17:34:32 UTC 2013

Hash: SHA1

On 09/19/2013 03:10 PM, Matthew Miller wrote:
> On Thu, Sep 19, 2013 at 02:11:05PM -0400, Daniel J Walsh wrote:
>> In a container image, you do not need to install selinux-policy*, since 
>> selinux policy is not supported within the container.  From the
>> containers point of view SELinux is disabled. Because of this you can
>> probably also eliminate policycoreutils, although other packages might
>> suck it back in.
> Yeah, the "medium" container is kind of a work-in-progress on this front.
> I thought I put selinux-policy on the minus list of packages -- I'll take
> a look at what's pulling it in.
> I'm really interested in your thoughts on how selinux might work in this 
> brave new world. :)
Well in its simplest form it would be used to stop one container from messing
with another container using MCS Separation.  virt-sandbox does this now, as
well as openshift and SELinux sandbox tool. Basically you run all processes
within the container with a single type container_t.  And all the writable
content is container_file_t.  Then you use a unigue MCS label for each
container and its content.  container_t:mcs1, can not touch container_t:mcs2.

We can also define constraints outside the container like, what ports the
container is allowed to use, or what capabilities are available. Whether it
can mount, mknod ...

We can also do transitions within the container.  For example the container
runs as container_setup_t and then executes myapp_exec_t it will transition to
container_t.  But the whole time nothing within the container knows about SELinux.
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


More information about the cloud mailing list