User: Password:
|
|
Subscribe / Log in / New account

Berrangé: Building application sandboxes with libvirt, LXC & KVM

On his blog, Daniel P. Berrangé writes about a new application sandbox tool that uses libvirt, LXC (Linux Containers), and KVM. It is based on some of the ideas behind the SELinux sandbox but uses KVM or LXC to isolate the application from the rest of the OS. "People also generally assume that running a KVM guest, means having a guest operating system install. This is absolutely something that is not acceptable for application sandboxing, and indeed not actually necessary. In a nutshell, libvirt-sandbox creates a new initrd image containing a custom init binary. This init binary simply loads the virtio-9p kernel module and then mounts the host OS' root filesystem as the guest's root filesystem, readonly of course. It then hands off to a second boot strap process which runs the desired application binary and forwards I/O back to the host OS, until the sandboxed application exits. Finally the init process powers off the virtual machine. To get an idea of the overhead, the /bin/false binary can be executed inside a KVM sandbox with an overall execution time of 4 seconds."
(Log in to post comments)

Berrangé: Building application sandboxes with libvirt, LXC & KVM

Posted Jan 18, 2012 21:43 UTC (Wed) by yokem_55 (subscriber, #10498) [Link]

On my laptop:
me@mybox ~ $ time /bin/false

real 0m0.002s
user 0m0.001s
sys 0m0.001s

4 Seconds? That would have to be one seriously untrusted (I'm looking at you acroread) application for that kind of overhead to be worthwhile.....

Berrangé: Building application sandboxes with libvirt, LXC & KVM

Posted Jan 18, 2012 22:08 UTC (Wed) by gevaerts (subscriber, #21521) [Link]

Isn't that 0.004 seconds?

Berrangé: Building application sandboxes with libvirt, LXC & KVM

Posted Jan 18, 2012 22:12 UTC (Wed) by cmorgan (guest, #71980) [Link]

Yep. Original poster appears to be comparing to the time given in the article which is 4s.

Berrangé: Building application sandboxes with libvirt, LXC & KVM

Posted Jan 18, 2012 22:15 UTC (Wed) by yokem_55 (subscriber, #10498) [Link]

To be clear, what I put in my previous post is without any sandboxing. So, the KVM sandbox has at least a pretty serious amount of setup-breakdown overhead. How it would affect execution performance outside of that is unknown, but say a process per tab web browser sandboxed in this manner would introduce a fair bit of a delay in opening a new tab if processes aren't sharing a sandbox...

Berrangé: Building application sandboxes with libvirt, LXC & KVM

Posted Jan 18, 2012 22:56 UTC (Wed) by gevaerts (subscriber, #21521) [Link]

I promise I'll read first next time

Berrangé: Building application sandboxes with libvirt, LXC & KVM

Posted Jan 19, 2012 0:39 UTC (Thu) by robert_s (subscriber, #42402) [Link]

There's sandboxing and there's sandboxing.

I don't think anyone ever intended for it to be used for that kind of sandboxing.

Berrangé: Building application sandboxes with libvirt, LXC & KVM

Posted Jan 19, 2012 2:42 UTC (Thu) by pspinler (subscriber, #2922) [Link]

I wonder how LXC sandbox start / stop timings compare to KVM/QEMU. I might have to spin up a fedora system to test this against ...

-- Pat

Berrangé: Building application sandboxes with libvirt, LXC & KVM

Posted Jan 19, 2012 9:02 UTC (Thu) by danpb (subscriber, #4831) [Link]

If you tell virt-sandbox to use LXC, then the time to run /bin/false is approx 400 milliseconds on my host.

Berrangé: Building application sandboxes with libvirt, LXC & KVM

Posted Jan 19, 2012 8:53 UTC (Thu) by HeMan (subscriber, #35944) [Link]

I think you should compare it to start a full Linux distro in a KVM, that is somewhat more than 4 seconds.

Berrangé: Building application sandboxes with libvirt, LXC & KVM

Posted Jan 19, 2012 8:56 UTC (Thu) by danpb (subscriber, #4831) [Link]

The reason I chose /bin/false is because its native execution time is as close to zero as you'll get, so by running it in a sandbox you'll only be measuring the fixed sandbox startup/teardown overhead. In the real world scenarios you clearly would not want to be running such short lived commands inside a KVM based sandbox, unless there were serious trust issues, instead you'd more likely want to pick the LXC based sandbox them which has a fraction of a second startup overhead.

You also have to bear in mind the startup/teardown costs for a traditional virtual machine with a full operating system in it. This is more like 30-60 seconds (or worse), so 4 seconds is really quite a dramatic improvement, which opens the door to many possible new use cases. This has already been demonstrated in the real world by the libguestfs library, which uses a KVM sandbox for doing nearly all its work.

As an example of other use cases for sandboxes... the transcoding of audio or video files - a process often operating on untrusted data which can take several minutes & thus a 4 second overhead is inconsequential. Building Deb/RPM packages - a tool like Koji used in Fedora currently has to deploy full VMs to secure its build environment, and even then this does not isolate the brew agent / mock part from the RPM build except with traditional UNIX DAC permissions. You could use the sandbox tools to strongly confine the actual build process & avoid the need to deploy complete OS installs for builders. By reducing the time to start a guest from 60, to < 4 seconds, it means it is practical to start a new transient VM for each individual build executed, instead of having one long lived VM for all builds. Or in a desktop scenario, the ultimate goal would be to sandbox firefox, so you could have multiple concurrent instances strongly isolated from each other (eg one for internet banking, another instance for all general browsing activity).

In summary, although 4 seconds may sound alot, this overhead is really inconsequential for a very wide variety of application sandboxing use cases.

Berrangé: Building application sandboxes with libvirt, LXC & KVM

Posted Jan 20, 2012 13:20 UTC (Fri) by ortalo (subscriber, #4654) [Link]

Have you studied much more different alternatives (like SELinux protection rules for example) for similar use-cases?

PS: Long ago I would have predicted that full virtualization for security sandboxes were overweight - but reality seems to contradict me every other month - so I'd like to know more about that trend compared with "traditional" mandatory rules implementations.

Berrangé: Building application sandboxes with libvirt, LXC & KVM

Posted Jan 20, 2012 20:50 UTC (Fri) by raven667 (subscriber, #5198) [Link]

I'm sure people said the same things when protected memory VM systems started coming out that gave each process its own address space.

Berrangé: Building application sandboxes with libvirt, LXC & KVM

Posted Jan 24, 2012 2:22 UTC (Tue) by i3839 (guest, #31386) [Link]

Hm, our ptrace based jailer does /bin/false in 0.006 seconds, compared to 0.002 without jail. Perhaps ptrace-based jailing isn't as slow in practice as I thought, compared to some alternatives.

Berrangé: Building application sandboxes with libvirt, LXC & KVM

Posted Jan 19, 2012 0:09 UTC (Thu) by psomas (guest, #48733) [Link]

QubesOS [1] seems similar. Qubes-OS design/trade-offs (virtualize everything, and partition apps in isolation domains/VMs) seem more reasonable to me. Virtualization will incur a constant overhead on every app you run, but it won't cripple performance that much -- it'll be probably unnoticeable by the user.

Maybe for not-frequently-run, short-lived apps (but long-lived enough to 'amortize' the 4s+ latency), this tool is more well-suited.

Note: Sandboxing/security with both solutions assumes that hypervisors/containers/etc are safe, and trusted. The recent KVM/Linux SCSI bug proves that this is not the case, and to some extent justifies both QubesOS' decision to choose XEN over KVM, due to a smaller TCB, and Theo De Raadt (controversial?) opinion on virtualization.

[1] http://qubes-os.org/Home.html

Berrangé: Building application sandboxes with libvirt, LXC & KVM

Posted Jan 19, 2012 8:56 UTC (Thu) by intgr (subscriber, #39733) [Link]

> Sandboxing/security with both solutions assumes that
> hypervisors/containers/etc are safe, and trusted.

No, every security engineer realizes that software will never be 100% secure. The whole point of this excercise is adding more layers of security. Normally an attacker could compromise the whole machine with one root exploit, now they'd have to break the virtualized kernel first, and *then* break out of VM sandbox via a hypervisor vulnerability.

> The recent KVM/Linux SCSI bug proves that this is not the case, and to
> some extent justifies both QubesOS' decision to choose XEN over KVM, due
> to a smaller TCB

This one bug proves nothing -- it's just one out of many. Xen, over the years, has had its share of vulnerabilities too. What makes you think that Xen has a smaller contact surface than KVM? They seem to be doing pretty much the same thing.

Berrangé: Building application sandboxes with libvirt, LXC & KVM

Posted Jan 19, 2012 9:11 UTC (Thu) by danpb (subscriber, #4831) [Link]

> > Sandboxing/security with both solutions assumes that
> > hypervisors/containers/etc are safe, and trusted.
>
> No, every security engineer realizes that software will never be 100%
> secure. The whole point of this excercise is adding more layers of
> security. Normally an attacker could compromise the whole machine with one
> root exploit, now they'd have to break the virtualized kernel first, and
> *then* break out of VM sandbox via a hypervisor vulnerability.

Indeed, I would never argue that sandboxing with hypervisors or containers is a foolproof security solution, it is merely one part of a wide toolbox of security techniques that can be applied. It is worth considering the practicality of different security techniques. SELinux is a great technology for strongly confining applications, but as most people know, actually writing policy for applications can be quite a daunting task. By choosing to deploy a KVM application in a sandbox, as well as being confined by the guest OS kernel DAC permissions, it also gets confined by SELinux via the sVirt feature in libvirt. So you get much of the benefit of MAC permissions on the application, without actually having to write a dedicated SELinux policy for it.

Actually that's not true...

Posted Jan 19, 2012 10:03 UTC (Thu) by khim (subscriber, #9252) [Link]

No, every security engineer realizes that software will never be 100% secure.

You forgotten one very important adjective: every security engineer realizes that sufficiently large software will never be 100% secure. This is important. You can completely check and verify small piece of code (few kilobytes is practical limit - and then it takes years to find and fix all bugs: see history of Wii, PS3 and XBox360 exploits), but for megabytes of code (something close in complexity to Linux kernel or hypervisor) it's of course impossible. Sometimes few kilobytes is enough.


Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds