I am having some problems with the design/implementation of sVirt for Fedora- virtualization on Fedora 11. 1. I am a longtime user of Fedora since FC1 and, prior to that, I used Red Hat Linux. 2. I am a big fan of SELinux and have been using it since FC3 and always run in enforcing mode. I get upset/angry when someone suggests disabling SELinux to "fix" my problems. If there is a "bug", report it and get it fixed ... do not ignore it. 3. I have also been a longtime user of VMware. However, with Fedora- virtualization on Fedora 11, I decided to "change my problem set" and give Fedora-virtualization a try ... especially since I now have an AMD Phenom II 940 which supports hardware virtualization. I have researched and found a number of documents which provide some of the goals, etc. for sVirt. However, I have hit some undesirable characteristics and bad side effects in dealing with ISO images. First of all, sVirt changes/sets the file context for any virtual disk, ISO image, or device (e.g., /dev/sr0) ... I am not sure what happens with LVM logical volumes because I have not tried them yet. I understand that, with mandatory access control, a process should be denied access to all resources except those which have been explicitly permitted. I assume this is the reason for setting/changing the file context. For ISO images, this is BAD! I have an apache (httpd) server running which has access to my repository of ISO images. After I create a virtual guest and point to an ISO image in the repository, the apache server can no longer see that ISO image! Bad, BAD! Yes, I know restorecon will fix things up but this should not happen in the first place. Another (related) problem is that I cannot use an ISO image file on a read-only mounted file system. Why? Just what is being protected here? As currently implemented, there is no protection between guests with respect to their individual virtual disk files. This really does need doing and it will be interesting to see how it will be done by SELinux (assuming this is protected by Fedora-virtualization applications software is not good enough). Some suggestions: 1. I am not sure what should be done with real devices such as /dev/sr0. 2. For files on read-only file systems, don't do anything ... they are protected about as much as they can be. 3. For files in /var/lib/libvirt/images, set the file context as is now done. This is also true if I locate my read/write virtual disk (file) elsewhere. 4. For ISO files, maybe there should be a new/special file context which allows sharing between processes ... it would be explicit but it would allow sharing ... maybe something like "public_content_t". 5. Maybe implement a switch which disables SELinux enforcing (and does not change the file context of ISO files) for Fedora-virtualization. 6. Maybe the switch should be by guest. - - - - - OK, I can see where locking down Fedora-virtualization with mandatory access control would be very interesting to some organizations such as NSA but that this would be used in a very rigidly controlled and limited system. But, this stuff has to be usable in other environments too. - - - - - - Finally ... IMHO, the design/implementation of SELinux for Fedora- virtualization was a bit of a quick-and-dirty approach ... do what we know how to do. I suggest that maybe some SELinux folks and some key Fedora- virtualization (especially libvirt) folks should take a week off (or maybe just a weekend), go off somewhere where you will not be bothered, and the figure out what should be done ... not "how" ... just the "should" at first. Then after some time has passed so that folks have had time to think about it, have another "session" where the "how" is considered and a roadmap is created. Just some food for thought. Gene -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
