• 1
The apache module recently put into Fedora does something similar with categories for vhosts. It can be similarly used to confine vhosts into their document root.

Question for you:

Is there a way to tell from inside a virtual machine that the host has SVirt enabled?

For example. If I'm paying for utility computing services..and I want the protection of SVirt when shopping for a hosting solution...can I verify that SVirt protection is in place or will I need to take my provider's word for it?


Being able to interrogate the host is what we are trying to stop. You would have to find a vulnerability to know for sure. :^(

From a utility computer(or is it "infrastructure as a server" now) customer point of view... its a catch-22. It's protection that I can only be sure is enabled by proactively attempting to breach it. Somehow I doubt providers will look kindly on that sort of quality of service verification activity from their customers. I guess the fallback here is customers can start demanding some sort of breach of contract penalty if hosting companies have misconfigured their SVirt related policy. And then providers would have a monetary incentive to make sure SVirt protections are working.


Not enough customers are in the know to realize they should be demanding such features. I think enough people have to start offering it first, or it needs to be legislated (which i'm not a fan of), so that consumers are used to expecting it.

The understanding of the risks here is still evolving. I don't expect this sort of feature to be a bullet point for hosting providers soon...not till RHEL6/Centos6 come with this out of the box and providers gain some experience with setting this up on their production iron and feel confident to advertise it as a differentiator. I expect Red Hat to talk this issue up as part of the marketting in RHEL6. In the meantime, providers are going to need to dabble with the capability of the SVirt enabled tools in Fedora 12.

My point is.. for those customers who are aware...and do go shopping for this sort of protection..its difficult for them to hold their vendors feet to the fire in terms of quality assurance. There maybe a business opportunity here for Red Hat to certify hosting vendors as SVirt managed since I can't easily verify it myself as a customer.


The interface of pola-run sounds nicer.

For example replacing:
qemu -cdrom cd.iso -hda myhdd.img
pola-run -B --prog=qemu -a=-cdrom -fa=cd.iso -a=-hda -faw=hdd.img
means that qemu can only read from cd.iso, read and write to hdd.img and can read /usr etc. I find the interface of pola-run very convenient when I want to safely run a command on some untrusted input. It is a pity that it hasn't been ported to recent versions of glibc.

Why can't standard Unix accounts provide the isolation of virtual machines from each other that you're going for? SELinux only adds restrictions to that, so it would seem sufficient to give each virtual machine its own account and make the disk images mode 600, owned by that uid. I guess SELinux could help out by preventing the virtual machine from calling chmod() on those files but I don't see what else it buys you here.

DAC protections would be helpful also

I am not sure that qemu can currently run without at least running with certain capabilities.

According to SELinux policy virtual domains required these capabilities.

allow virt_domain self:capability { kill dac_read_search dac_override };

I guess qemu could be reworked to not need these capabilities and you could run them as a non priv user. Then you could give libvirt a group of UID's to run each virtual instance under. I think a sVirt security plugin could be written to do this.

However this would not give you the fine grain control that SELinux can give you.
For example if you had a database on your system that was world readable then the virtual instances would be able to read it, and the DAC permissions would not stop it. Similarly world write, chmod as you said. Executing setuid applications, all would be allowed. Etc.

I guess you could bring this up on the virt mailing list for discussion on potential security module solution.

Loved your blog, but i am not able to figure out the difference between the MCS and MLS. I mean libVirt is using MLS labels or MCS, and what difference it will make if the VM is Label with MCS and MLS. Thanks

Well if you are running without mls policy you will be using MCS labeling.

If you have not configured anyting in libvirt for static labeling, then you are using MCS. If you want to use MLS you need to install selinux-policy-mls, then modify the /etc/selinux/config, relabel, reboot, and you are almost there. But it will probably not be a pleasant experience.

Thank You for your reply

Sorry i saw this comment after a long time. But i appreciate your reply. The difference is a lot clearer to me now.

Just wondering currently the whole fedora 20 file system has SElinux enabled with user_home_t:s0:c0,c1023 and when i boot a qemu Virtual Machine and it will have svit_t s0:c66,c350 and svirt_image_t:s0:c66,c350. So if i just boot a normal qemu process without libvirt by mistake i use the same hda wich has svirt_image_t:s0:c66,c350 it is able to access that image file fully, i am able to read and write on the hda and the previous qemu libvirt process(s0:c66,c350) is able to read it but unable to write on. Isn't the libvirt(sVirt) process supposed to protect the confined image file from being accessed by a normal user process? i hope the question is clear. This kind of makes sVirt useless. Even a new qemu libvirt process is made to access the same file it will change the category of that file to what it generates for it self which this time lefts the old qemu process without read or write access. But thing is the new qemu process should not be able to access the confined(secured) image file at all.

Edited at 2014-01-28 08:40 pm (UTC)

Re: Thank You for your reply

No the normal user is running as unconfined_t and is allowed to do what he wants. So if you run qemu directly rather then out of libvirt it will run as unconfined_t:s0-s0:c0.c1023, and it able to read/write the image file.

If you run it out of libvirt, libvirt will relabel the process and the image files.

  • 1

Log in