On 04/17/2013 03:49 AM, yue wrote:
hi,all
a qemu-kvm process and its disk(image file) have the same MCS(s0:c111,c555). it express
this process have access to this image.
i do not know the power to access its image file is the max or min?
Neither. sVirt is built by coming up with a unique label, and we get
more uniqueness by picking two MCS labels at once than we do by just one
label at a time. We are not using MCS in the traditional sense of
higher vs. lower access rights, but merely as a distinguishing label.
if any other power this process(domain) has?how much?
When sVirt is enabled, qemu can only access items that are properly
labeled. But all labeling is supposed to come from libvirt
automatically. You can control the labels by modifying the <seclabel>
element of your domain XML, but you should NOT be changing SELinux
labels by hand for any resource managed by libvirt. If libvirt isn't
setting labels correctly, that's a bug in libvirt.
i want to know the exact power a qemu-kvm process has besides
access its image file ,other kinds of files,dirs etc.
The goal of sVirt is to make it so that a qemu process can only access
things listed in the domain XML.
my test case:
after start a guestVM(its disk xml ,cache='none' error_policy='stop'),
make some modification on its files and save them.
then go to hypervisor, modify the MCS of guestVM's image file.
The moment you modify SELinux labels of resources behind libvirt's back,
all bets are off. Treat the labels as an opaque implementation detail
of how sVirt works, and only use libvirt to manage sVirt.
1.i can read those files(cache=none)?it should not be so. why?
2.then modify files and save, the guestVM hang, it is paused on UI. this is right qeum
process can not write again. why this guestVM is hang? and can not be resumed
3.look at audit info. denied { write } for pid=52162 comm="qemu-kvm".
that pid is 52162, is not my qemu-kvm's pid? why?
In Linux, pid really means thread id; qemu-kvm spawns one thread (and
thus a different pid) per host core that is running a vcpu visible to
the guest. The audit log is probably reporting the pid of the thread
that got denied because of label mismatch, rather than the pid of the
process that spawned that thread.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org