On Monday 06 July 2009 12:31:53 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). Neat! OK, this is starting to make more sense to me. I like the idea of using the MCS policy to protect guests from each other. As far as I can see, the MCS policy stuff has not been implemented yet ... at least with libvirt-0.6.2 ... I am still waiting for 0.6.5 to appear in Fedora 11 updates-testing. I hope this MCS policy stuff gets implemented for Fedora 11 so I can give it a try. As far as protecting the host from guests, the act of defining a guest in the current implementation changes the host and impacts other processes (my httpd example). > > > 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. I can understand the desire to provide some protection out of the box. However, having the file contexts changed automagically should be an explicit decision by the system/security administrator ... not something done by default. If this is to be allowed, there should be an sVirt or SELinux switch which needs to be set to enable automagically setting the file context. Naturally, all this needs documentation. BTW, when the MCS policy protection gets implemented, there needs to be something which manages the categories. When you have one, two or three guest, this can be manual but when you get a lot of guests (I currently have two defined), this can be a problem to manually manage. I still believe that ISO image files (and perhaps other shared virtual disk files) need a special file context that allows sVirt and other processes to access the files ... make this read-only access if that is better. Question: ... When the MCS policy stuff is implemented, will two or more guests be able to share a single ISO image file ... they should! Yes, I know this makes things a lot more complicated but I believe it is necessary. After all, doing the targeted policy is a lot more complicated than the old strict policy but was necessary to have something actually usable. Gene -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
