Add some SELinux info I've pieced together

[SvenDowideit]

Signed-off-by: Sven Dowideit SvenDowideit@home.org.au

[moxiegirl]

You should state the problem immediately after the example -- the example context is clear given the position of the sentence and the references. Two bits of information are important the fact that the host is runing SELinux and the container cannot write. If you state these two ideas at the first and last bit of the sentence you leverage the two "power" ends of a sentence the beginning and the end.

You should define SELInux as it is the first occurence on this page.

In your work around, you don't need the "at the time of this" clause. That fact is assumed by the reader. It isn't clear when or where for running the chcon command. It is an SELinux command so --- run it on the host and state this clearly. Does the user need to set the context before mounting --- not clear but I assumed that the answer was yes.

---

If your host is using SELinux (Security-Enhanced Linux), you can mount the /var/db directory but the container cannot write to /data1. Instead, attempts to write to /data1 result in a Permission denied message and an avc: message in the host's syslog. This is because the container has no knowledge of the host's SELinux policies.

To work around this, change the security context on the /var/db directory. This command applies an appropriate SELINUX policy to the directory:

chcon -Rt svirt_sandbox_file_t /var/db

Then, rerun the container; the /data1 is now writable.

[thaJeztah]

Perhaps @rhatdan (being "Mr SELinux") can give this a quick read as well?

[rhatdan]

Well merge in the -v /src:/dest:Z

But if you are going to put out this document, I would rewrite it from most secure to least secure.

The chcon command is documented in the docker-run man page.

[rhatdan]

I also cover some of these subjects in these articles.

http://opensource.com/business/14/7/docker-security-selinux
http://opensource.com/business/14/9/security-for-docker
http://opensource.com/business/15/3/docker-security-tuning

Bottom line SELinux is a labeling system. If you are going to volume mount an object into the container, you need to make sure it is labeled correctly for the container.

chcon -t svirt_sandbox_file_t PATHTOVOL

Will do this.

Anything else is lowering the security of the container.

[jamtur01]

Ping back to @SvenDowideit

[SvenDowideit]

@rhatdan I'm struggling to put an order of 'goodness' on these (and really, its not an ordered list, its a list with different tradeoffs).

take chcon -t svirt_sandbox_file_t PATHTOVOL

If I understand SELinux labeling right, this means that PATHTOVOL is now accessible to the host, and all containers - and also (maybe - I didn't find any clear documentation on this) LXC, libvirt backends like qemu/kvm?

When I made this PR, I was looking for the info that you wrote up in your latest blog post - as I really wanted to show how to create a set of custom process labels - I've hit a number of other snags in the mean time, so that's a WIP.

@moxiegirl merci - I'll get to re-writing stuff later when I've groked enough of the technical details.

[rhatdan]

chcon -R -t svirt_sandbox_file_t PATHTOVOL

Will make the volume read/write by all containers if the containers can some how access the volume. It will most likely not make the path available to other CONFINED processes on the system. Basically by executing this command, you identify the data as "Container Data". Rules in SELinux say that the "Container Processes" can read/write "Container Data" Since the data's MCS Label is s0 (The default) it is read/write by all container processes. If lxc or libvirt-lxc launch containers with the same "Container Process Label" they will be allowed to also Read/Write the Container Data.

The problem with most people writing data is that they think about adding ALLOW rules rather then changing the label on the content. For example if I bind mount in /var/lib/foobar into a container, SELinux will complain about the "container process label" read/writing var_lib_t which is the default label of content in /var/lib. If I write a policy rule to allow this, I have now setup a rule where the container can read any content in /var/lib if it is labeled var_lib_t. If on the other hand I set the label to svirt_sandbox_file_t, then I have identified the content as COntainer Data and the container processes will ONLY be allowed to read/write content in /var/lib/foobar.

My order of preference would be
0. Merge the docker run -v /var/lib/foobar:/var/lib/foobar:Z patch
1 Fix the label on /var/lib/foobar
2. Write new policy for a container process to just it to read/write var_lib_t (Most difficult)
3. Run the container process with SELinux disabled "docker run --security-opt label:disabled"
3a. Run the container process with an unconfined SELinux label "docker run --security-opt label:type:unconfined_t"
4. Disable SELinux in docker (Remove --selinux-enabled) from the docker daemon startup. On Red Hat Based OS, you can do this by editing /etc/sysconfig/docker
5. Disable SELinux on the system.

[thaJeztah]

Thanks for kicking in @rhatdan and adding your input!

[SvenDowideit]

@rhatdan yup (and merci!) - that confirms my general thinking.

I think we need to add --privileged into the list - both to show that its an option, and needs careful consideration - because turning off SELinux would apply to either the entire system, or all containers, whereas --privileged would only apply to that one container.

mentioning 3 and 3(a) alone make this PR worth working on

[rhatdan]

Yes I would put --privileged as #3.5 But in some cases it could be considered #6 Since turning off all Security of the container is drastic also.

[ehazlett]

ping @SvenDowideit

[SvenDowideit]

sorry, been on PTO, and now working to catch back up.

[jamtur01]

@SvenDowideit Catch up already. :)

[LK4D4]

@SvenDowideit @moxiegirl what's status here? Can we merge it?

[moxiegirl]

@LK4D4 I haven't seen any commits in response to the various comments. So, I'm gonna say no.

[LK4D4]

then ping @SvenDowideit again

[SvenDowideit]

I'm going to shelve this - I havn't had time to work on RHEL stuff. I'll reopen when I find time to ⚫