On Sat, 2009-07-04 at 12:13 -0400, Gene Czarcinski wrote: > 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. ls -alZ /dev/mapper | grep volume2 brw-rw----. root disk system_u:object_r:svirt_image_t:s0:c168,c894 vg_mybook-lv_volume2 > 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 There was a libvirt/svirt test-day earlier but dwalsh was not there, and svirt was not mentioned by anyone. I know svirt is a work in progress. I have not tested the iso image thing but sounds like you have a good point there. My svirt setup is very generic and i did not notice any such issues. > -- > fedora-selinux-list mailing list > fedora-selinux-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
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
