[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:
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:


                                                            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.

    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

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.

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