Is virtualisation a viable alternative to MAC ?

Posted Jul 31, 2010 23:15 UTC (Sat) by haradats (guest, #44782)
In reply to: Is virtualisation a viable alternative to MAC ? by copsewood
Parent article: AppArmor set to be merged for 2.6.36

The following slide by James Morris might help. In my personal opinion, virtualization is a nightmare for security.

http://namei.org/presentations/svirt-lca-2009.pdf

Is virtualisation a viable alternative to MAC ?

Posted Aug 1, 2010 0:22 UTC (Sun) by dlang (guest, #313) [Link] (2 responses)

I think that saying that virtualization is a nightmare for security is significantly overstating the problem.

I do think that the people who think that virtualization is the solution to all security problems are also drastically overstating the benefits and under estimating the risks.

Is virtualisation a viable alternative to MAC ?

Posted Aug 1, 2010 0:31 UTC (Sun) by haradats (guest, #44782) [Link]

> I do think that the people who think that virtualization is the solution to all security problems are also drastically overstating the benefits and under estimating the risks.

Agreed.

Two things were in my mind when I wrote "a nightmare". While MAC tries to build up security from the bottom (TPM, boot, system call), guest OS can directly bound to the bottom. And the internal of guest OS can hardly observed (therefore confined) from the host (or hypervisor). However, "a nightmare" was too much as you suggested.

Is virtualisation a viable alternative to MAC ?

Posted Aug 1, 2010 19:56 UTC (Sun) by drag (guest, #31333) [Link]

I believe that to properly assess the advantages of virtualization and determine how appropriate it is for a orginization it's extremely important to have the correct attitude and approach to it.

Virtualization should be mostly thought of as a cost saving mechanism and that is about it. It's a abstraction you can to use to accomplish something cheaply that otherwise would take more resources, be more difficult, or cost more.

And actually you end up sacrificing security for that lower 'TCO'.

For example:

You want to isolate network services so that if one is hacked the other will still be secure. Traditionally you would simply have to purchase multiple machines to run each service. However that is expensive and uses lots of space... so what you can do is use virtualization to isolate each service on one machine while saving money.

In that case I am sure that everybody here would agree that running multiple services on multiple physical machines is going to provide higher security then running multiple services in multiple VMs on a single machine.

So hence your trading some security for lower cost.

So it's all about proper perspective and it makes it much easier to judge the proper use of virtualization then if you get sidetracked and start thinking about security advantages. Virtualization vendors need to concentrate on promoting their products through the discussion of cost saving measures, not sort of any illusionary security advantage.

------------

Similar problems happen when people start discussing file systems, raid, and backups.

Is virtualisation a viable alternative to MAC ?

Posted Aug 1, 2010 12:15 UTC (Sun) by copsewood (subscriber, #199) [Link] (2 responses)

Yes these slides do help answer this question. Perhaps the combination of MAC at the host level and virtualisation at the user level will work better than either in isolation, because this keeps the MAC policy much simpler (hence fewer human errors) with less need for local customisation, so more manageable than when using MAC in a shared login situation ? MAC in this scenario seems to protect against bugs in the virtualisation layer.

Saying that virtualisation is less secure than a previous scenario of separate hosts for different jobs seems obvious, but if the previous scenario is single host multiple logins (e.g. for shared webhosting) then virtualisation even with just different UIDs and DAC seems to offer better security than what existed before. I think this because this direction is how the hosting of my own websites has migrated, though I would expect my upstream VM provider to be looking at and implementing the kind of DAC solution as proposed in the slides.

typo

Posted Aug 1, 2010 13:36 UTC (Sun) by copsewood (subscriber, #199) [Link] (1 responses)

"implementing the kind of DAC solution" in my previous comment should have read MAC.

typo

Posted Aug 1, 2010 20:09 UTC (Sun) by drag (guest, #31333) [Link]

Absolutely.. a properly designed MAC policy combined with virtualization should yield superior results.

But the thing to remember, especially with container-style virtualization, is that even when combined with a MAC policy mechanism losing a single VM + having a single kernel-level exploit can easily lead to the loss of your entire machine.

For a full VM solution it's a bit better as the attacker has to find a exploit in the VM software first and theoretically it is going to be more difficult then finding a local kernel exploit. But I don't know much about that.

So in this case it's still good to think of it as your losing security compared to having dedicated hosting in exchange for much lower cost.. and the provider can use MAC to recover some of the lost security. But it's still not as nice as having a separate real machine. :)

Is virtualisation a viable alternative to MAC ?

Posted Aug 2, 2010 2:34 UTC (Mon) by raven667 (subscriber, #5198) [Link]

Reading that it wasn't clear to me how the security framework was going to help. The attack surface between the guest and the hypervisor is mostly in the form of abstracted hardware. I could see a buffer overflow or something against the virtualized hardware or tools interface but that would generally put you right in the hypervisor which would be game over man, right?

When it comes to the security of the whole system I would be far more concerned about the millions of network applications and OS exploits than buffer overflows in the handful of hypervisors which are in active use. A new exploit might be found on a common hypervisor platform, which is sufficient reason to put systems with radically different security zones on different hardware, but it probably isn't the biggest risk, probably not even in the top 10.

There is a lot more benefit to AppArmor, SELinux, TOMOYO, etc. in preventing applications with security vulnerabilities from accessing files, devices and system calls so that exploit payload isn't able to work.