Re: svirt_lxc_net_t -> container_t and nsswitch_domain

[Lukas Vrabec]

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.