Red Hat Bugzilla – Bug 852609
[sVirt] selinux user in seclabel changed
Last modified: 2014-06-18 03:19:06 EDT
Description of problem: For privilige user, the selinux user used be system_u, now is unconfined_u. Version-Release number of selected component (if applicable): libvirt-0.10.0-0rc1.el6.x86_64 How reproducible: always Steps to Reproduce: 1.start a domain and check # virsh list --all Id Name State ---------------------------------------------------- 1 libvirt_test_api running # virsh dumpxml libvirt_test_api ... <seclabel type='dynamic' model='dac' relabel='yes'> <label>107:107</label> <imagelabel>107:107</imagelabel> </seclabel> <seclabel type='dynamic' model='selinux' relabel='yes'> <label>unconfined_u:system_r:svirt_t:s0:c249,c664</label> <imagelabel>unconfined_u:object_r:svirt_image_t:s0:c249,c664</imagelabel> </seclabel> ... # ll /var/lib/libvirt/images/libvirt-test-api -Z -rw-r--r--. qemu qemu unconfined_u:object_r:svirt_image_t:s0:c780,c1009 /var/lib/libvirt/images/libvirt-test-api 2. save/restore domain # virsh save libvirt_test_api /tmp/save Domain libvirt_test_api saved to /tmp/save # ll -Z /tmp/save -rw-------. root root unconfined_u:object_r:virt_tmp_t:s0 /tmp/save The save file inherit dir label, it's expected. # virsh restore /tmp/save Domain restored from /tmp/save # ll /tmp/save -Z -rw-------. root root system_u:object_r:virt_content_t:s0 /tmp/save after restore, the file seclabel changed and with system_u, this is expected. So, unconfined_u is not expected. 3. Actual results: changed from system_u to unconfined_u Expected results: remain no change from previous versions. Additional info:
BTW, I have ever raised this issue on bug 851491, and Peter has committed patches to fix them together on bug 851491.
(In reply to comment #2) > BTW, I have ever raised this issue on bug 851491, and Peter has committed > patches to fix them together on bug 851491. As the note in: https://bugzilla.redhat.com/show_bug.cgi?id=851491#c6 (Note that the labels are different - probably because the git version isn't labeled correctly -, but the setting still fails) The label problem still exist, this bug is for tracking this only.
Tested with latest libvirt: libvirt-0.10.0-1.el6.x86_64 This problem still exists.
The latest libvirt updates the SELinux user and role from the label that is used as base for label generation with user and role from the current SELinux context of libvirtd process. I don't know if this is an expected behavior but it seems to be changed by this commit: commit 4e365df44fb1b1b93186d6be006ea445e1409a02 Author: Daniel P. Berrange <berrange@redhat.com> Date: Fri Aug 10 14:27:51 2012 +0100 Honour current sensitivity and category ranges in SELinux label generation Currently the dynamic label generation code will create labels with a sensitivity of s0, and a category pair in the range 0-1023. This is fine when running a standard MCS policy because libvirtd will run with a label system_u:system_r:virtd_t:s0-s0:c0.c1023 With custom policies though, it is possible for libvirtd to have a different sensitivity, or category range. For example system_u:system_r:virtd_t:s2-s3:c512.c1023 In this case we must assign the VM a sensitivity matching the current lower sensitivity value, and categories in the range 512-1023 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Daniel, can you confirm this?
Yes, as described above, for process labels we now copy the user + role from libvirtd's context into the VM's context, instead of hardcoding 'system_u:system_r'. For disk labels we now copy the user from libvirtd's context into the VM's disk context, instead of hardcoding 'system_u'.
Will this bug be changed to NOTABUG?