sVirt

[Gene Czarcinski]

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