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.
>
> Dan,
>
> container_t don't have auth_use_nsswitch in container policy, is it bug
> or you removed it for some reason?
>
> Thanks,
> Lukas.
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
read /etc/passwd.
Yes, it make sense.
Thanks,
Lukas.
This is probably a case where it would be great to easily extend
content
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
auth_read_passwd(container_t)
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.
>>
>> Thanks,
>>
>
--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.