Customizing container types

In my previous blog, I talked about about container types container_t and svirt_lxc_net_t. Today I get an email, asking about the new container_t type replacing svirt_lxc_net_t.

On 05/23/2018 11:50 PM, Dustin C. Hatch wrote:
I recently upgraded some of my Docker hosts to CentOS 7.5 and started getting "Permission Denied" errors inside of containers. I traced this down to any container that mounts and uses /etc/passwd from the host (so that UIDs inside the container map to the same username as on the host), because the SELinux policy in CentOS 7.5 does not allow the new container_t domain to read passwd_file_t.  
The old svirt_lxc_net_t domain had the nsswitch_domain attribute, while its replacement, container_t, does not. I cannot find any reference for this change, so I was wondering if it was deliberate or not. If it was deliberate, what would be the consequences if I were to make a local policy change to add that attribute back? If it was not deliberate, I would be happy to open a ticket in Bugzilla. 

First let's remove the misconception, container_t was not a new type replacing svirt_lxc_net_t, it was a rename (typealias) of the old type.  

But the more important question was, why did I remove the access `nsswitch_domain` access.  This access allowed containers to read all sorts of user information is a container escaped.  The reason it was there originally was to allow virt-sandbox to care up a host into several containers, as opposed to the way 'Docker' ran containers each as separate unigue userspaces.

When Docker experienced a CVE a couple of  years ago where a container process was able to escape to the host, a security analyst was surprised on what a container process was allowed to read by default by SELinux.  And of course reading /etc/passwd seemed to like something we should prevent.  I agreed, and decided to tighten policy by removing this ability.  I still think it is the right decision.

The emailer goes on to ask if he were to add the attibute back would that be an issue, I say no, if you use case is to allow containers to read user data out of /etc/passwd then you can/should modify the policy to allow it.  Lets look at how.

Create a TE file that looks like the following:

# cat mycontainer.te
policy_module(mycontainer, 1.0)
gen_require(`
type container_t;
')
auth_use_nsswitch(container_t)
# make -f /usr/share/selinux/devel/Makefile
# semodule -i mycontainer.pp

 Now container processes on systems with this policy module will be able to interact with the host in all the different ways that you can use nsswitch, which means you can not only read /etc/passwd, but also communicate with sssd, and remote IPA and authentication databases.  If you want to write a tighter policy that simply allows  your containers to read /etc/passwd, you could write a module like:

# cat mycontainer.te
policy_module(mycontainer, 1.0)
gen_require(`
type container_t;
')
auth_read_passwd(container_t)
# make -f /usr/share/selinux/devel/Makefile
# semodule -i mycontainer.pp

Obviously I would recommend the second one.

Bottom Line

I am trying to balance container security with the ability to run most container workloads.  When you have a use case where these conflict, SELinux has the flexibility to allow you to customize the policy.

Error

Anonymous comments are disabled in this journal

default userpic

Your reply will be screened