James Morris wrote:
This is to announce the formation of the sVirt project, which aims to integrate SELinux and Linux-based virtualization (KVM et al).
The idea has been discussed a few times over the last year or so, and in recent weeks, a few Fedora folk (such as Dan Walsh, Daniel Berrange and myself) have put together some requirements and had some preliminary technical discussions.
The requirements document and initital technical considerations are included below inline for review and discussion.
In a nutshell, we'd like to be able to apply distinct security labels to individual VM instances and their resources, so that they can be isolated from each other via MAC policy. We want this to "just work" when configuring and managing VMs via the libvirt toolchain, e.g. provide a simple option during VM creation to make the VM "isolated", and have the toolchain do all the labeling and policy configuration behind the scenes. Greater detail may be found in the requirements document.
If you wish to contribute, please reply to this email with any enhancements to the requirements, technical ideas, issues etc. I'd suggest joining the libvir-list (in the to: line) if not already on it, as that is where the integration work is expected to happen.
There's also a wiki page: http://selinuxproject.org/page/SVirt
------------------------------------------------------------------------
11 Aug 2008
sVirt: Integration of SELinux and Linux-based Virtualization
Requirements and Design Considerations v1.0
1. Introduction
This document establishes a set of functional and technical requirements for integrating SELinux with Linux-based virtualization (i.e. Linux-as-hypervisor schemes such as KVM/Qemu amd lguest).
Note that non-Linux hypervisor models such as Xen are not covered explicitly in this document, although may be afforded some MAC coverage due to shared infrastructure (e.g. libvirt). Non-Linux hypervisor models may considered further at a later stage.
Also, while this document focuses on SELinux as the MAC scheme, consideration should be given to ensuring support for other label-based MAC schemes.
1.1 Rationale
With increased use of virtualization, one security benefit of physically separated systems -- strong isolation -- is reduced,
This issue can always be readily resolved by going back to physically separated hardware. The strength of isolation of a virtual machine mechanism is one of the important characteristics that should be considered when it is chosen over a hardware isolation scheme, but the systems available today appear to do a pretty good job on this, so I would like to see some evidence of this claim before accepting it as a primary premise.
an issue which may be ameliorated with the application of Mandatory Access Control (MAC) security in the host system.
Ok. I've been using VMs for 30 years and MAC for 20, and to my mind the only way this statement can possibly be true is if both the MAC system and the VM system are inadequate to their respective tasks.
Integration of MAC with virtualization will also help increase the overall robustness and security assurance of both host and guest systems. Many threats arising from flaws in the VM environment, or misconfiguration, may be mitigated through tighter isolation and specific MAC policy enforcement.
You are not going to solve any problems of misconfiguration this way, you are just going to make the environment more complicated and prone to misconfiguration.
By incorporating MAC support into the virtualization toolchain and documentation, users will also be able to make more use of the MAC security capabilities provided by the OS.
Would you back this assertion? VMs seem no better a vehicle for MAC integration than user sessions in any way that I can see.
1.2 Use-cases
The following use-cases have been identified:
o Providing virtualized services with a level of isolation similar to that previously afforded by physical separation.
As I mentioned before, this doesn't seem to make any sense. I can see the value in running a MAC system under a VM in limited cases, but the other way around does not seem particularly rational.
o Increased protection of the host from untrusted VM guests (e.g. for VM hosting providers, grid/cloud servers etc.).
I can see where someone who is not familiar with VMs might think this is plausible, but looking at the interfaces and separation provided by VMs makes it pretty clear that this isn't even a belts and braces level of extra protection.
o Increased protection of VM guests from each other in the event of host flaws or misconfiguration. Some protection may also be provided against a compromised host.
Flaws and misconfiguration will not be helped by this.
o Consolidating access to multiple networks which require strong isolation from each other (e.g. military, government, corporate extranets, internal "Chinese wall" separation etc.)
The VMs provide this. Isolation is easy. Sharing is what's hard.
o Strongly isolating desktop applications by running them in separately labeled VMs (e.g. online banking in one VM and World of Warcraft in another; opening untrusted office documents in an isolated VM for view/print only).
And how does a MAC environment help this when we still barely have SELinux X11 limping along?
o Forensic analysis of disk images, binaries, browser scripts etc. in a highly isolated VM, protecting both the host system and the integrity of the components under analysis.
You're just restating "stronger isolation".
o Isolated test environments, preventing e.g. simulated trades from entering a production system, leakage of sensitive customer data to internal networks etc.
You're just restating "stronger isolation".
o General ability to specify a wide range of high-level security goals for virtualization through flexible MAC policy.
What does that mean in this context? How is it useful? Usually by the time someone decides that they need to use physical separation or that they can simulate it with VMs they've already decided that fancy software schemes like MAC are insufficient, and that's often because the MAC system (SELinux or B&L) is too hard to set up for their uses.
2. Current Situation
SELinux is already able to provide general MAC protection to Linux-based virtualization, such as protecting the integrity and confidentiality of disk images and providing strong isolation of Linux hypervisor processes from the rest of the system.
There is, however, no explicit support for Linux-based virtualization in SELinux, and all VMs currently run in the same security context. Thus, there is no MAC isolation applied between VMs.
You can run them with different MLS values, can't you?
3. Functional Security Requirements
3.1 Strong isolation between active VMs
Running different VMs with different MAC labels allows stronger isolation between VMs, reducing risks arising from flaws in or misconfiguration of the VM environment. For example, the threat of a rogue VM exploiting a flaw in KVM could be greatly reduced if it is isolated from other VMs by MAC security policy.
You can run them with different MLS values, can't you?
3.2 Improved control over access to VM resources
.... OK, I get the picture. You really want to run VMs under SELinux. Go wild, but I think you are significantly overstating the value and creating a project where a a little bit of policy work ought to handle all but the most extreme cases. DAC, MAC, Containers, VMs, and separate hardware are all mechanisms for providing (in ascending order) measures of isolation. It makes sense to tighten a DAC system by adding MAC, or running a MAC system under a VM, but to each the sort of isolation it is good at.