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. _______________________________________________ selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/selinux@xxxxxxxxxxxxxxxxxxxxxxx/message/JGPQAYAEU4DCLDAERRJJDV6MX73V7OZH/
