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.