On 07/06/2009 12:31 PM, 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> > > 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 > I also have made a patch to virt-manager to do this from the GUI, although it has not been merged yet into Rawhide. -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
