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 >
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
