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? 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 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"? I am not trying to be nit-picky about this stuff. I have and do support SELinux as a significant security improvement an applaud the efforts of NSA, Red Hat, Fedora, and others in making it a reality. I run SELinux enforcing mode and prefer that everything protected should always be the case. However, there is a difference between shared resources (files) and owned resources (files). I am also a new fan of Fedora Virtualization and want to see it succeed. That you can run Fedora, Red Hat, Solaris, *BSDs, etc. as guests is a fantastic capability. Locking down guests with SELinux is a significant capability. I believe I have some understanding of why organizations such as NSA and related organizations want to have locked down (restricted access) guests. However, the only true secure computer systems is an isolated one with the power off (assuming adequate physical security). We need security implemented while we "keep our sanity". The question: what is "good enough" security as oppose to "perfect" security? When SELinux was first introduced in Fedora, the security policy was strict. Well, that turned out to be a bummer and many folks disabled SELinux. So, a targeted policy was developed and has evolved to cover more and more of the system. With Fedora 11 sVirt has been introduced as the latest evolution. But, as currently implemented, sVirt breaks protections for other (previously protected) processes. I am just saying that it needs some fine tuning or perhaps re-thinking. Gene -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
