svirt_lxc_net_t -> container_t and nsswitch_domain

[Dustin C. Hatch]

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.

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.

Thanks,

-- 
♫Dustin

[Lukas Vrabec]

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.

>  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.
>  
>  Thanks,
>   

-- 
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.