On Mon, 2009-07-06 at 12:31 -0400, Stephen Smalley wrote:
On Mon, 2009-07-06 at 11:12 -0400, Gene Czarcinski wrote:
On Monday 06 July 2009 09:29:25 Stephen Smalley wrote:
I believe that changing any file context should not be done. Depend on the rules in the security policy or any added with semanage apply. And then let something like public_content_t and public_content_rw_t be OK too.
Mmmm, this makes so much sense that I think I will bugzilla this.
The reason that it presently relabels the disk image is that it is auto-generating a unique security context (unique category pair) for each VM, and then assigning that category pair to both the qemu-kvm process and to the disk image to isolate instances from one another.
OK does this "unique security context" protect guests from each other?
It provides some degree of isolation between them, yes. By default, the TE policy is being used to protect the host from the guests (by restricting what types are accessible to svirt_t), and the MCS policy is being used to isolate the guests from one another (by using unique category sets for each guest).
I do not understand what is being protected and who are we protecting from. [with respect to ISO image files and other shared files]
I am not talking about a guest's virtual disk in /var/lib/libvirt/images (or whatever).
Regardless, I do NOT believe that sVirt should be changing file contexts. The system (security?) administrator should be controlling what contexts a file has ... it should not be happening under the sVirt covers. This is especially true when it effects other processes (my httpd example).
ISO image files should be sharable between guests as well as other processes on the system with a common file context.
Setting the file context also causes other problems when the ISO image exists in a read-only file system.
There are definitely situations where relabeling should not happen. But the sVirt designers wanted some default protection out of the box, without requiring manual configuration by an admin. Thus automatic generation of MCS category pairs for each guest, with those categories applied to the process and to the virtual disk image.
There is also a static configuration option where you can specify the desired context for the VM, in which case it shouldn't relabel the disk image.
Is there additional information somewhere about using this "static configuration option"?
First, you need to use virsh edit to add/replace the seclabel entry with something like this:
<seclabel type='static' model='selinux'> <label>system_u:system_r:svirt_t:s0:c1</label> </seclabel>
Thanks for the tip. Static works better for me.
system_u:system_r:svirt_t:mybookvolume2 root 2933 13.1 3.2 2420860 266352 ? Sl 19:21 0:25 /usr/bin/qemu-kvm -S -M pc -m 2047 -smp 2 -name mybookvolume2 -uuid bede1797-dea4-af3d-29c7-cf216f822f1a -monitor pty -pidfile /var/run/libvirt/qemu//mybookvolume2.pid -boot c -drive file=,if=ide,media=cdrom,index=2 -drive file=/dev/mapper/vg_mybook-lv_volume2,if=virtio,index=0,boot=on -net nic,macaddr=54:52:00:70:cc:5e,vlan=0,model=virtio -net tap,fd=17,vlan=0 -serial pty -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:0 -k en-us
Note the type='static' part, which prevents libvirt from clobbering it later with a dynamically generated context.
Then you need to manually label the image file - it won't do that for you once you've defined a static label, e.g.: chcon system_u:object_r:svirt_image_t:s0:c1 /var/lib/libvirt/images/vm1.img