11–20 of 54 posts
author here. hi world!
Glad to see you've added a lot of detail to your research. It's very necessary!
Earlier quoted context omitted.
Fugly? Compared to what alternatives? The offerings from Microsoft are even fuglier .
FreeBSD jails, I would think.
I can't give up Debian's package system, though, so I'm left hoping that kFreeBSD will amount to something someday and I use Xen or KVM in the meantime... :-(
To do this efficiently they've had to make a bunch of changes on the VM side so the overhead is much smaller than an ordinary VM (of the order of 150ms and 20MB of RAM). I've also been looking at this and am hoping to give a talk about it at the KVM Forum in August (http://events.linuxfoundation.org/events/kvm-forum).
author here. hi world!
Hi Jesse! We got an audit from you last year (I was the one who pushed to get you to specifically look at our PaaS containerization). As a result I spent a while wrangling with Ubuntu LXC unprivileged containers, and now I know more about cgmanager than I wanted to. Glad to see you've added a lot of detail to your research. It's very necessary!
Earlier quoted context omitted.
I don't share your opinion. The Kernel exposes a collection of primatives (including but not limited to: cgroups, namespaces, and copy-on-write storage[1]) which can be used to create isolated sandboxes. The kernel itself doesn't bind the primatives together because I believe Linus would consider that "User space"...and I would agree. Instead this is left up to other tools like LXC. Also note, that higher level featu…
The original design wasn't intended to provide that kind of isolation, and the primitives that are exposed are retrofit; every new containerization design needs an audit that captures the entire exposed functionality of the Linux kernel. You can just skim this paper to see the problems: non-namespaced identifiers leak in procfs, UID "slides" expose containers to each others resource limits, there are non-namespaced n…
I could be wrong...but that path dependency seems to indicate that while they were implemented as more general kernel features...one of their motivating use cases was container isolation.
Can anyone more informed clarify the history for me?
I think what Intel are doing with Clear Containers is really interesting. They are encapsulating containers inside VMs, avoiding the security problems of containers. To do this efficiently they've had to make a bunch of changes on the VM side so the overhead is much smaller than an ordinary VM (of the order of 150ms and 20MB of RAM). I've also been looking at this and am hoping to give a talk about it at the KVM Foru…
Hope there was previous disclosure.
So I don't really see how this is considered a big vulnerability, unless the goal is security by obscurity, but then we could go even further and obfuscate the whole system.
>NET_RAW abuse
Hard to blame LXC/Docker for something that has to do with the configuration of the bridge, plus for some setups this is desired functionality.
>DoS
Some of these are interesting but I don't see how filling up the diskspace is a problem with containers and not operating systems in general, and I feel like a lot of these DoS attacks are all just basic OS limitations but I don't know enough to make an informed statement.