When getting hardware virtualisation running on my machine I noticed that xen couldn't find my file backed disk unless I put selinux back to permissive.
In /var/log/messages qemu-dm, ifconfig and python (running in the context of xend_t) are triggering a lot of denies.
Is this usual, or have I messed up my SELinux policy somehow?
Paravirt seems happy enough, and I could just add a "setenforce permissive" to the startup for whatever infrequently used full virt systems I build. It's just a bit strange as selinux had been surprisingly quiet so far on FC6.
Robert
On Mon, Nov 20, 2006 at 07:22:54PM +1000, Robert Thiem wrote:
When getting hardware virtualisation running on my machine I noticed that xen couldn't find my file backed disk unless I put selinux back to permissive.
In FC6 GA you had to make sure the file for the disk was under /xen to be labelled correctly. In rawhide (and I think latest FC6 policy) we're moving to /var/lib/xen/images. To see what the required dir is run
semanage context -l | grep xen_image_t
You can also define new locations any time you like using semanage,
eg
semanage fcontext -a -f "" -t xen_image_t '/some/directory(/.*)?'
Regards, Dan.
In FC6 GA you had to make sure the file for the disk was under /xen to be labelled correctly. In rawhide (and I think latest FC6 policy) we're moving to /var/lib/xen/images. To see what the required dir is run semanage context -l | grep xen_image_t You can also define new locations any time you like using semanage, eg semanage fcontext -a -f "" -t xen_image_t '/some/directory(/.*)?'
I had a look at that when I first came across the problem and found it mentioned on the list archives.
AFAIK that's fine. All the images come up with the system_u:object_r:xen_image_t context when I do an ls -Z.
"semanage fcontext -l | grep xen_image_t" yields the expected /extra/xen(/.*)?all files system_u:object_r:xen_image_t:s0 along with "/xen(/.*)?" and the new "/var/lib/xen/images(/.*)?"
What when SELinux is enforcing all I get is: avc: denied { search } for pid=3662 comm="python" name="/" dev=sda8 ino=2 scontext=system_u:system_r:xend_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=dir [sda8 is my /extra partition]
When it's permissive then I see: "ifconfig" being denied write to the cdrom devices qemu-dm denied access to dsp
If I have it set in SDL I also getqemu-dm denies on various things that seem to be related to bringing up the display window (.xauth* files, xdm temp folders, ".X11-unix" and "tmp" dirs, "X0" socket, ".xauthBLAHBLAH").
... (Continued - apparently trying to add tabs and spaces to a web based e-mail window can lead to premature mailing :> )
None of these turn up with the paravirtualisation.
My HVM config is straight from the xmexample.hvm except for the disk line and activating SDL and sound. I don't remember destroying my SELinux settings except to set contexts on /extra/xen (selinux policies scare me), but I do run the closed source NVidia drivers (Of Doom!) which do do something to SELinux, so who knows.
Anyway - I lived without SELinux for FC1-5. I imagine I can live with the occasional permissive mode until FC7.
Robert
Am Dienstag, den 21.11.2006, 00:38 +1000 schrieb Robert Thiem:
In FC6 GA you had to make sure the file for the disk was under /xen to be labelled correctly. In rawhide (and I think latest FC6 policy) we're moving to /var/lib/xen/images. To see what the required dir is run semanage context -l | grep xen_image_t You can also define new locations any time you like using semanage, eg semanage fcontext -a -f "" -t xen_image_t '/some/directory(/.*)?'
I had a look at that when I first came across the problem and found it mentioned on the list archives.
AFAIK that's fine. All the images come up with the system_u:object_r:xen_image_t context when I do an ls -Z.
"semanage fcontext -l | grep xen_image_t" yields the expected /extra/xen(/.*)?all files system_u:object_r:xen_image_t:s0 along with "/xen(/.*)?" and the new "/var/lib/xen/images(/.*)?"
relabeling doesn't fix the problem?
Happy Day. Thorsten