Walsh: Secure Virtualization Using SELinux (sVirt)

Since security is the overall goal here, has SELinux introduced more vulnerabilities then it's prevented? I think not.

> this completely undermines your credibility.

No need to undermine me :) Stick with what arguing what I said. Unless you have something to gain by my turning out to be stupid or otherwise incompetent.

/me breaks out the link so grown ups on the Internet can be grown up again - http://en.wikipedia.org/wiki/Ad_hominem

It's the perfect kernel from a security standpoint. Something with nearly
zero functionality has about zero chance of ever having a security
problem!!

To do anything with it you have to run Linux on top of it... which gets you
what, exactly? A system with nearly zero hardware support running a
application environment that is less secure and has less performance then
if you just ran it on bare hardware.

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

And that goes pretty much the same for "lightweight" hypervisor like Xen or
ESX.

Lets look at Xen.(I am much more familiar with Xen, but I am sure that ESX
is in a similar situation)

In order to run anything you have to take a Linux kernel, shove it up into
Ring 1 and then have your hypervisor run in Ring0.

So.. theoretically you might have some security improvements, but in
practice the Linux environment needed for you to do anything and it has
pretty much full access to your hardware and all your guests. (anybody ever
heard of a term called "DMA"?)

Sooo.. in fact your _worse_ off. Because now your not just dealing with the
Xen hypervisor your dealing with all the code that is in Linux kernel and
then all the code that is required for the hardware emulation and I/O
virtualization and all that stuff.

And Xen is no featherweither either. 300k LoC I think.

So your "lightweight" hypervisor solution weighs in at about 2-3 times
amount of code running on your system to get the same work done as just
running Linux on the bare metal.

-------

To get rid of the dependence on Linux your going to have to write hardware
drivers, create a sort of userland interface, and then all the code
neccassry for management and I/O redirection/emulation and all that...

So now your hypervisor is essentially a Linux competitor and is huge, or
you have vastly reduced feature set.

You can't get away from the fact that if you want to support hardware and
have similar functionality that you get from a kernel your essentially just
going to have to write a kernel eventually. You can call it a hypervisor,
but a rose by any other name will require about the same amount of
functionality.

Meanwhile the "heavyweight" KVM code that turns Linux into a hypervisor is
what? 30k? 50k? If you want to go by LoC that is actually quite a bit less
then is required by Xen.

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

People need to get the idea out of their heads that virtualization can
increase security. This is a flawed way of looking at it.

The ideal solution is to have separate machines for each service you want
to deploy. But that is expensive. Virtualization can reduce costs.. and
that is the best way to look at it, I figure. VM's are a cost cutting
thing, not a security thing. When you can not afford to do the security
right (or at least the best way) then you use virtualization.

> The evolution of seL4 is continuing within NICTA, and it is the basis of ongoing research activities here at NICTA. However, it is also the subject of commercialisation activities, and thus is currently proprietary. We are endeavouring to release seL4 in the future, but the time-line and exact nature of the release is yet to be decided.

Thanks, but no thanks. There are already plenty of other free microkernels out there (L4, Mach, Coyotos, HURD, Minix, etc.)

no, I would not expect to see someone trying to use AA to create generic seperation between virtual machines.

I could very easily see someone configuring AA to lock down a specific virtual machine to keep it from accessing things that another virtual machine is allowed to access. it would be based on the knowledge of what that particular virtual machine is supposed to access.

but since it's possible to run the virtual machines as seperate users, it would also be very easy to use the standard unix permissions to isolate them from each other, with probably 90% of the security for <<10% of the effort of using something like SELinux (and probably <50% of the effort of using AA)

with AA, if you have well defined applications (which I freely admit many/most people don't) it's relatively easy to create an AA profile for it. each AA profile is pretty much independent from other AA profiles, so if you just check them for overlapping you can combine them easily.

SELinux doesn't have tools (at least not well publicized tools) that let you do this. instead you have to understand the entire system (all local uses as well as all remotely accessible applications) and then make one big policy that defines all files correctly for all the applications (and you still have the problem of creating the appropriate tags for new files that are created), it's not something that your normal sysadmin can do. it's very hard for even extremely experienced security people to do (and it doesn't help that the common response to problems is "you don't know enough to be tinkering there, just use what your distro provides you with")

SELinux is more powerful than AA, no question, but it's complexity (and interactions in it's config) make it hard enough to use that most people don't bother (and if you think that the distro default configs are appropriate, I disagree with you, they are far too open because the sitros can't possibly know what's appropriate for a particular installation)

AA is far less powerful, but (if it was available in the default kernel) far more likely to be used.

I am not an AA user, because (having been burned a few times), I make it a policy to not use features that aren't in the kernel.org kernel unless I _absolutely_ have to, and so far my need for additional local security have not been that high yet.

-jef