sVirt

[Gene Czarcinski]

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