[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[libvirt] Re: [ANNOUNCE][RFC] sVirt: Integrating SELinux and Linux-based virtualization



James Morris wrote:
On Sun, 10 Aug 2008, Casey Schaufler wrote:

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.

I suspect you misunderstood an important aspect of this in that we are targeting Linux-based virtualization, where the VMs are running inside Linux processes. In this case, the isolation depends on DAC in the host, and the idea behind sVirt is to apply MAC security to these VMs and their resources.

Currently, all such VMs run with the same security label, and all of the resources accessed (e.g. disk images) have the same labels.

We are simply proposing a mechanism to allow distinct security labels to be applied to these entities, which in the simplest case, will allow MAC policy to enforce isolation between them.

Well, let's look at the situation and see what sort of risk we're
talking about. A VM running inside a Linux process is subject to the
same kinds of vulnerabilities as any other program too be sure. So
the problem you are looking to address is that the label of the process
is based on the label of the program file. This problem is hardly unique
to VMs, as anyone who wants to run two web servers with different MLS
values will tell you.

...
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.

I don't think this is valid as an absolute statement.

You're correct. It is a strong opinion that I hold. My strong
opinions and $4.55 will get you a nice coffee at Peets.

...
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.

I disagree.

VMs are software, and all software has bugs. If you can break out of the VM in Linux-based virtualization, you can probably get to all of the other VMs on the system (they are running in the same DAC and MAC contexts).

Assuming again that you're using program based MAC. A traditional
B&L system where the process retains its label through exec() would
not have this shortcoming.

Applying distinct labels allows MAC policy to be enforced by the host kernel so that such breaches are contained within the isolated host VM process.

Or are you saying that you don't think hypervisors can be broken out of ?

Not any more than web servers, name servers, or game programs,
many of which don't do particularly well in a program based MAC
environment, either.

      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.

I don't see why not. With MAC containment, if, say, a web server on the host was compromised, an attacker may be prevented from interfering with the VMs running on the system. This is already true to some extent with coarse-grained MAC.

Sure, there are some flaws and misconfigurations that will be caught,
but I would never count on it as a security feature in an environment
that matters.

...

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.

The proof of concept code is indeed simple policy/labeling changes, although we want to ensure that we fully understand the requirements, and implement a flexible and generally useful scheme.

Support for this also needs to be built directly into the virt toolchain so that the user is provided with a complete solution, rather than a collection of pieces.

How do you envision the Virt toolchain changing to support SELinux?
I confess to being pretty curious about what you think needs to change.

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.

So, in the case of a Linux-based VM running as a process in a DAC context, we are indeed tightening a DAC system by adding MAC.

Yeah, you're right there.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]