| Well -- 'no attack surface' might be simplifying things a bit too much, as you do need a way to interact with the hypervisor or the privileged host to actually get your data written to disk and your network packets out on the wire.
Each such interaction can contain bugs, some of which might be exploitable. Even with Xen or KVM you do have an attack surface: * guests can send network packets to the host, which interacts with the networking code on the host. If exploitable you get to execute code/DoS the host. Hopefully not because then so could any other remote machine. * guests can execute instructions which get emulated / need extra privilege checks done in the hypervisor. See recent vulnerability regarding MSR registers in Xen. * guests execute hypercalls which obviously interacts with the hypervisor. Bugs here, if exploitable, can be nasty. * guests need to read/write their data to disk. Are we sure they can't read the data of a (possible already deleted) other VM? * guests read/write from memory ... was the memory of previously deleted/crashed/migrated guests properly scrubbed? Can any of the hypercalls/etc. be used to read another guest's memory, or access uninitialized memory containing pieces from old guests? ... Of course the attack surface of a hypervisor is smaller than that of a full kernel (where you also have a lot of syscalls, disk formats, etc.), but that doesn't mean hypervisors are suddenly bulletproof. I think this quote sums it up quite well: http://marc.info/?l=openbsd-misc&m=119318909016582&w=2. Also have a look at the PDF referenced in that thread. The question is where does LXD stand from a security pov. between these simplified categories (no order implied): - running multiple different processes as same user - running processes in different LXC containers as root-in-container on same host - running processes in different LXC containers as non-root on same host - running multiple processes as different users - running processes in different LXC containers as non-root on same host - running root processes in different KVM VMs on same host - running non-root processes in different KVM VMs on same host - running root processes in different Xen/domU VMs on same host - running non-root processes in different Xen/domU VMs on same host - ... Or in other words if you get an account/container/VM on a shared machine from a hosting provider using technology X, how does that compare to getting an LXD container from a hosting provider?
(provided that other unknown users can run LXD containers on the same machine as yours). |
In the pure sense, a hypervisor doesn't need to do anything except create a virtual machine. It doesn't need a way to interact with a user or even the vm once it is created. I have written a bare metal, type 1 hypervisor that did nothing but key log. The guest never made a hypercall and wasn't aware that it was a guest at all. Side note, I'm not an expert. Hypervisor research is just for fun.
We know there is an attack surface on LXD immediately because of the REST API and its interaction with containers. Any resource mediation also exposes an attack surface. Resource mediation is difficult, but not impossible. The attack surface really depends on implementation.
With my limited knowledge of the linux kernel, I can imagine a kernel running in its own vm, a vm for every container, and every container sharing read-only access to the single kernel. Each container could also be isolated via the same memory protection. I don't know enough to say that's possible. I think you're more knowledgeable than I am about lxc and the kernel in general. Any thoughts on this?