Re: Relocating /etc/libvirt and Selinux label

On 05/17/2018 04:44 AM, Gionatan Danti wrote:
> Hi list,
> in relocating /etc/libvirt to another filesystem, I encountered another "lnk_file read" permission problem.
> 
> First, I setup a selinux equivalence rule between the original path (/etc/libvirtd) and the new one (/tank/kvm/etc/libvirt/).
> 
> Original layout/label:
> [root@whitehole ~]# ls -alZ /etc/ | grep libv
> drwx------. root root   system_u:object_r:virt_etc_t:s0  libvirt
> 
> After relocation and context restore (via "chcon -h -t virt_etc_t libvirt"):
> [root@whitehole ~]# ls -alZ /etc/ | grep libv
> lrwxrwxrwx. root root   system_u:object_r:virt_etc_t:s0       libvirt -> /tank/kvm/etc/libvirt> 
> After relocation, libvirtd does not start, and audit2allow shows "allow virtd_t virt_etc_t:lnk_file read". Relabeling the link file with "restorecon -F /etc/libvirtd" produces the following output:
> 
> [root@gdanti-lenovo etc]# ls -alZ | grep libv
> lrwxrwxrwx. root root   system_u:object_r:etc_t:s0       libvirt -> /tank/kvm/etc/libvirt/
> 
> Now libvirtd correctly starts. However, I have some questions:
> - is this the correct mode to relocate a directory?

This is one valid way to do it; bind mounts are another.  A bind mount would avoid the problem of introducing a new file (the symbolic link) into the pathname lookup and thus avoid a new permission check.

> - this is not the first "lnk_file read" problem I see. Why does the selinux policy prevent this kind of accesses? Do they pose security concerns? Or does the policy simply not expect to deal with relocated daemons?

In this case, it is merely the fact that in a stock system, there are no symbolic links with that type and thus no reason to ever have allowed it in the default policy.  In general, restricting access to symbolic links is useful in preventing symlink attacks and unauthorized information flow.  It appears that this access is allowed in Fedora 27/28.

> - after "restorecon -F /etc/libvirtd", which causes a relabel with etc_t type, libvirtd correctly starts. Why does the policy enable etc_t link reads, at the same time denying virt_etc_t link reads?

Likely because there are symlinks under /etc already that are widely accessed and thus that is allowed in the default policy.
NB You generally do not want to use chcon, because that context will be overridden upon the next filesystem relabel unless you also add an entry to file_contexts via semanage fcontext.  Even in that case, better to add first via semanage fcontext and then run restorecon.

> - how can I avoid the problem (short of using bind mounts)?

You can always generate a local policy module using audit2allow to allow the symlinks to be read.

_______________________________________________
selinux mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]/message/EZJBBYDT2YZ62UDVFRMXOOJVMNZXD7QY/