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 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?
- 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?
- how can I avoid the problem (short of using bind mounts)?
Thanks.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@xxxxxxxxxx - info@xxxxxxxxxx
GPG public key ID: FF5F32A8
_______________________________________________
selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx
