Previous Entry Share Next Entry
Labeling of xen images
A place people sometimes trip with SELinux is the labeling of files.  SELinux requires files to be labeled correctly in order to function.  Discretionary Access Control has the same requirement in that file must have the correct permissions and ownership. If a file does not have the correct permissions it can not be read, written or executed.  Similarly if a file is not labeled correctly SELinux will prevent read/write/execute as well as many other permissions and transitions.

xen and qemu virtuallization has this problem alot.  SELinux requires that images used by xen be labeled xen_image_t, and images used by qemu/libvirt be labeled virt_image_t.  virt_manager currently does not do this by default and it creates the images in the current directory by default, which I hope they change.  However there are directories where the image files will automatically get the correct label. 

Fox xen we have the labeling

/xen(/.*)?    system_u:object_r:xen_image_t:s0
/var/lib/xen/images(/.*)?    system_u:object_r:xen_image_t:s0

With /var/lib/xen/images the preferred location

If you don't have a /xen directory, you need to create it and then reset the labeling.
# mkdir /xen
# restorecon /xen

For qemu/libvirt we have the labeling

/var/lib/libvirt/images(/.*)?    system_u:object_r:virt_image_t:s0

If you were to store the xen images somewhere else, you would need to set up the labeling to that place.  SELinux uses regular expressions to map files to file context so at the end of the directory specification you need to add (/.*)?  which tells SELinux to label everything labeled in the directory and its subdirectories xen_image_t.

# semanage fcontext -a -t xen_image_t 'PATHTOIMAGEDIR(/.*)?'
# restorecon -R -V PATHTOIMAGEDIR

Note: If you are creating a whole new directory structure, you make need to label the entire directory tree xen_image_t. SELinux requires that a confined domain be able to list all directories in the path of the image.  New directories created in / get either labeled default_t or root_t, default_t directories are not usually allowed to be searched.   If you create the image in a directory tree that xen or virt are not allowed to list, you might need to build some custom policy.

If you were to store your xen images in /myxen/images/

You would execute
# semanage fcontext -a -t xen_image_t '/myxen(/.*)?'
# restorecon -R -V /myxen

You would do the same for libvirt/qemu except use virt_image_t.

  • 1
Ah, I actually wanted to blog this.

Some notes: restorecon should be using -v instead of -V. I didn't know about virt_image_t type, so I learnt something new. It looks like virt-manager tries to save images to /var/lib/xen/images which will assume xen_image_t type I think. I'm guessing.


Yes restorecon -v is correct.

virt_image_t is only in rawhide. We are probably going to be introducing other types as we look into confining virt images. I would like to be able to take a virt image and confine it to only be able to listen on http ports, which would allow us to confine an Operating System running in a virtual machine without the Operating System running SELinux or even knowing about it.

Image a Windows XP Server running iss.

Images created in a directory that is labeled xen_image_t will be labeled xen_image_t, similarly images created in a directory labeled virt_image_t will be labeled virt_image_t

Thanks Dan.

But wouldn't that be confusing to have different types for different Virtualization technologies? It is clear that if one uses xen_image_t for an image, it is an image created for Xen. But it is also logical that virt_image_t be used for the same image. Sure, we can make sure that xen_image_t is a type alias of virt_image_t, but how can one ensure that the right type is used when writing policies?


It probably makes sence to alias the two types.

Especially if qemu begins to be able to manage xen images.

I will modify policy in Fedora 9 for this.

Re: It probably makes sence to alias the two types.

Thanks Dan.

  • 1

Log in