Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The new hypervisor LXD

ubuntu.com

Post reply on HN
Print view View original

71–80 of 80 posts

Re: The new hypervisor LXD

#71

Post by cwyers »

reidrac wrote: post #54
cwyers wrote: post #38

Earlier quoted context omitted.

There's a bit more to it than that, though. systemd as an init system was originally conceived as a way to improve Upstart; the reason that systemd decided to go its own way rather than contributing to Upstart is because of Canonical's CLA. That I think is a key point to this discussion -- in order to contribute to an open-source project run by Canonical, they insist upon you giving them more rights to the code you g…

"assigning Canonical the ability to re-license the code outside of the GPL" I think is more about ownership and IP than re-licensing. Copyright assignment adds value to Canonical as company, eg in case it is acquired.

These aren't mutually exclusive thoughts; for GPL-licensed content, the ability to relicense the code is pretty much the only benefit that ownership confers over the GPL. It seems strange to assert that having this ability adds value for Canonical in an acquisition, if the acquirer isn't interested in using it.

Now, I have no problem with anyone who wants to sign the CLA and believes that Canonical is acting in good faith. But Canonical is asking for additional value from contributed code than what the GPL provides, and isn't compensating people for this value. Some people have a problem with that, and it makes it harder for Canonical-hosted projects to get community involvement or to be adopted by other distros, where maintainers have to choose between signing a CLA so patches get accepted upstream or continuing to maintain their patches themselves.

Re: The new hypervisor LXD

#72

Post by edwintorok »

tmerc wrote: post #67
edwintorok wrote: post #63

Earlier quoted context omitted.

So what is the attack surface of LXD? Can the host kernel be compromised from inside an LXD container, i.e. does it provide the same isolation you get when running processes as different users on same kernel, or something more? For example if there is a local kernel privilege escalation / DoS / etc. bug that can be triggered by a non-privileged user (or a root-inside-container user) will those exploits still run insi…

A properly written vmm/hypervisor should have no attack surface. This won't be that since there's a rest api on LXD, which is one attack surface. DoS is still a problem but containers should provide mitigation for that. You can make the vmm prevent DoS, but it's better to keep the vmm small and light. As for local kernel privilege escalation, yes, it would still run, but it might not matter. In theory, the VMM can is…

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).

Re: The new hypervisor LXD

#73

Post by reidrac »

cwyers wrote: post #71
reidrac wrote: post #54

Earlier quoted context omitted.

"assigning Canonical the ability to re-license the code outside of the GPL" I think is more about ownership and IP than re-licensing. Copyright assignment adds value to Canonical as company, eg in case it is acquired.

These aren't mutually exclusive thoughts; for GPL-licensed content, the ability to relicense the code is pretty much the only benefit that ownership confers over the GPL. It seems strange to assert that having this ability adds value for Canonical in an acquisition, if the acquirer isn't interested in using it. Now, I have no problem with anyone who wants to sign the CLA and believes that Canonical is acting in good…

First of all, thanks for the comment. Down-votes don't add too much to the conversation.

I agree with you, but I remember reading that argument backing the CLA (defense in court, to increase the value of the company in case they want to sell it and to be able to close the code); I can't find a link though.

Re: The new hypervisor LXD

#74

Post by mrbill »

I've got a Debian system that I've got a couple of Debian VMs running on under qemu-kvm. I don't want Docker-style containers for specific apps; I need "full system image" virtualization - I wonder if this would be helpful for my use case?

Running the same kernel/version of OS is fine across my host system and the guests.

Re: The new hypervisor LXD

#75

Post by kozyraki »

amaks wrote: post #32

I'm wondering if LXD is based on the ideas from Stanford's Dune project ( http://dune.scs.stanford.edu/ ) to virtualize Linux processes.

Dune and its follow-up (IX, see http://csl.stanford.edu/~christos/publications/2014.ix.osdi....) can be used to secure and accelerate containers using Intel virtualization hardware. It'd be great if the community puts some energy behind these ideas.

Re: The new hypervisor LXD

#76

Post by zenlikethat »

peterwwillis wrote: post #70
shykes wrote: post #41

Earlier quoted context omitted.

I agree that Docker is easier to deploy than Openstack :) However... It always astounds me how some people massively over-estimate the size and influence of Docker's marketing... Why yes, of course! The way we got Google, Microsoft, Amazon and IBM to integrate it in their products is by ghost-writing PR fluff. That's also how we got 600 people to contribute 9,000+ pull requests over 18 months [1] [2] [3]. Not bad for…

I have two opinions: logical, and emotional. My logical opinion says that Docker is a useful tool which, though flawed in many ways, provides real value to a large number of users. I've even recommended Docker be used for new projects in my company, on the basis that it fits in well with what we're trying to do. My emotional opinion is that Docker trades on trends in startup-world, systems engineering and the open so…

> My emotional opinion is that Docker trades on trends in startup-world, systems engineering and the open source movement for the sole purpose of eventually generating revenue. This capitalistic perversion of what were before two idealistic and noble things (open source, engineering) is, quite honestly, abhorrent to me.

Except that the last thing anyone with a monetary stake in your business will do is tell you to open source your main product. The Docker project has fought damn hard, and continues to, to make sure that a carefully curated line between business and the open source project exists (see for instance the creation of the Docker Governance Advisory Board).

Re: The new hypervisor LXD

#77

Post by Rapzid »

josteink wrote: post #60
Rapzid wrote: post #59

To me the most interesting things here are that the kernel(and CPU's) will be getting hardware assisted process isolation as well as advancements being made around CRIU to support live migrating processes(and potentially entire cgroup trees?). This is good for everyone. Docker doesn't even use liblxc anymore by default, it uses libcontainer. Wonder why Ubuntu isn't getting behind libcontainer.. In any case, the stuff…

> Docker doesn't even use liblxc anymore by default, it uses libcontainer. Wonder why Ubuntu isn't getting behind libcontainer. Because not everyone wants what docker offers. Some people prefer and want the more VM-esque behaviour provided by LXC. To me LXC is the real deal, while docker offers limited convenience at the cost of flexibility and platform lock-in. And I have zero interest in that. I hope Ubuntu continu…

> Because not everyone wants what docker offers... Yes, I can understand this, but more specifically? That's hardly in the way of reasons.

> To me LXC is the real deal, while docker offers limited convenience at the cost of flexibility and platform lock-in. I'm not really sure what makes liblxc the "real deal" and "libcontainer" not? Would you care to expand on this though? The true flexibility you are alluding to is, I believe, provided by the kernel itself? Are you deriding libraries that abstract interfacing with these features? Where is the platform lock-in coming from? Docker has been making inroads into many non-linux platforms, even Windows recently.

> and then docker (or whatever the other hip thing of the month is) Are you suggesting Docker is a "flavour of the month"? That's... A unique perspective. In any case, as a counter point, I'd like to offer up that RedHat itself has partnered with docker via OpenShift. If one were looking for linux flavour of the month, I RedHat would be the LAST place they would look.

Re: The new hypervisor LXD

#78

Post by tmerc »

edwintorok wrote: post #72
tmerc wrote: post #67

Earlier quoted context omitted.

A properly written vmm/hypervisor should have no attack surface. This won't be that since there's a rest api on LXD, which is one attack surface. DoS is still a problem but containers should provide mitigation for that. You can make the vmm prevent DoS, but it's better to keep the vmm small and light. As for local kernel privilege escalation, yes, it would still run, but it might not matter. In theory, the VMM can is…

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 interac…

"No attack surface" was definitely simplifying too much, especially for LXD. I think I was trying to say that it is not impossible to mitigate those attacks.

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?

Re: The new hypervisor LXD

#79

Post by edwintorok »

tmerc wrote: post #78
edwintorok wrote: post #72

Earlier quoted context omitted.

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 interac…

"No attack surface" was definitely simplifying too much, especially for LXD. I think I was trying to say that it is not impossible to mitigate those attacks. 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 n…

I'm not worried about memory protection, there is HW support for that and it can be done. I'm slightly more worried about making sure that separate containers can't access each other's disks (via symlinks/hardlinks or overflowing some FS structures).

And I'm worried about the privileged kernel/hypervisor parsing/interpreting data from the unprivileged container. In that sense the situation is not much different from a server: if you can exploit a bug in the server you can run/perform actions with the server's privileges. Same situation with the kernel.

I'd wait until there are some more design/architecture docs about what LXD is exactly to say more though.

Post reply on HN