Re: svirt_lxc_net_t -> container_t and nsswitch_domain

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/




[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux