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>
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
--
Stephen Smalley
National Security Agency
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
