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,
selinux@lists.fedoraproject.org