11:41 p.m.
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.