On 05/26/2018 12:15 PM, Daniel Walsh wrote:
On 05/25/2018 10:26 AM, Lukas Vrabec wrote:
> 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
>> continer_t domain to read passwd_file_t.
> Yes we renamed svirt_lxc_net_t domain for container to container_t,
> which make more sense.
> Container SELinux security module is not distribution policy, so for
> this reason adding Dan Walsh to our discussion.
> container_t don't have auth_use_nsswitch in container policy, is it bug
> or you removed it for some reason?
Yes the reason is we did not want the container processes to figure out
which users are on the host.
During a container CVE, we were dinged on the fact that containers could
Yes, it make sense.
This is probably a case where it would be great to easily extend
from the host into a container.
>> 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.
It was deliberate and it is not an issue if you add it back, or
something tighter like
I believe allowing general containers to read users information should
be denied by default, but if you have a use case that you want to enable
it, I have no problem with it.
Software Engineer, Security Technologies
Red Hat, Inc.