sVirt

[Dominick Grift]

On Mon, 2009-07-06 at 12:31 -0400, Stephen Smalley wrote:
> On Mon, 2009-07-06 at 11:12 -0400, Gene Czarcinski wrote:
> > 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?
> 
> It provides some degree of isolation between them, yes.  By default, the
> TE policy is being used to protect the host from the guests (by
> restricting what types are accessible to svirt_t), and the MCS policy is
> being used to isolate the guests from one another (by using unique
> category sets for each guest).
> 
> > 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 are definitely situations where relabeling should not happen.  But
> the sVirt designers wanted some default protection out of the box,
> without requiring manual configuration by an admin.  Thus automatic
> generation of MCS category pairs for each guest, with those categories
> applied to the process and to the virtual disk image.
> 
> > > 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"?
> 
> First, you need to use virsh edit to add/replace the seclabel entry
> with something like this:
>   <seclabel type='static' model='selinux'>
>     <label>system_u:system_r:svirt_t:s0:c1</label>
>   </seclabel>

Thanks for the tip. Static works better for me.

system_u:system_r:svirt_t:mybookvolume2 root 2933 13.1  3.2 2420860
266352 ?   Sl   19:21   0:25 /usr/bin/qemu-kvm -S -M pc -m 2047 -smp 2
-name mybookvolume2 -uuid bede1797-dea4-af3d-29c7-cf216f822f1a -monitor
pty -pidfile /var/run/libvirt/qemu//mybookvolume2.pid -boot c -drive
file=,if=ide,media=cdrom,index=2 -drive
file=/dev/mapper/vg_mybook-lv_volume2,if=virtio,index=0,boot=on -net
nic,macaddr=54:52:00:70:cc:5e,vlan=0,model=virtio -net tap,fd=17,vlan=0
-serial pty -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:0 -k
en-us

> Note the type='static' part, which prevents libvirt from clobbering it
> later with a dynamically generated context.
> 
> Then you need to manually label the image file - it won't do that for
> you once you've defined a static label, e.g.:
> chcon
> system_u:object_r:svirt_image_t:s0:c1 /var/lib/libvirt/images/vm1.img
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-selinux-list/attachments/20090706/7c7c187b/attachment.sig>