Hacker News new | past | comments | ask | show | jobs | submit login

Thanks for sharing this link.

LXC has gotten me very excited about testing new linux services on a home box again. I always worry about exposing a server to the internet with any new services. The idea that a compromise on the box could leak everything that's on the box usually leads me to avoid exploring new services.

LXCs seem to give me hope that I could experience a compromise, but not lose everything.




LXC is not secure at the moment. root in a LXC container can lead to root on the host. There is unfortunately no good summary of the problems - here is my list (take it with a grain of salt - a lot of these problems are mitigated in docker.io and with AppArmor in Ubuntu):

- Without CONFIG_USER_NS and a newer kernel a lot of problematic things can happen. If /proc or /sysfs is mounted on the container DoS or escalation to root is possible: http://blog.bofh.it/debian/id_413 - At the moment no stock distro kernel has CONFIG_USER_NS enabled.

- There are some issues related to remounting filesystems rw and altering files

- Mounting cgroups in the container can also lead to problems - DoS and aquiring more ressources

- Capabilities. You stock Linux distribution won't boot without CAP_SYS_ADMIN (see man 7 capabilities) - there are a lot of other capabilities that could be troublesome.

- Not sure about this one: http://seclists.org/oss-sec/2011/q3/385

So for running services without CAP_SYS_ADMIN and with dropping a lot of other capabilities it can be considered somewhat safe. For everything else it's probably dangerous.

Not sure if all these issues are still a problem today but if you are running lxc on e.g. a current Debian Wheezy you have to know about all of them.


Many people have complained about CONFIG_USER_NS missing in Ubuntu [1] [2] [3] [4] [5].

Apparently the reason is that it's not compatible with XFS filesystem until 3.12 [6], and even though nobody uses [7] the XFS filesystem, backwards compatibility takes precedence over new features.

This is changed in 3.12, but it looks like the patch just missed the boat for Ubuntu Saucy [8].

[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/509808

[2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1085684

[3] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191600

[4] http://lwn.net/Articles/541787/

[5] http://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg...

[6] https://news.ycombinator.com/item?id=6761847

[7] By "nobody uses," I mean "I don't use it"

[8] http://lists.debian.org/debian-kernel/2013/09/msg00356.html


sure but you should not be mounting /sys and /proc in the container. just run one application. I do not understand the trend to run a whole Linux distro in a container. no one did that with chroots.


Why not? No virtualisation overhead, good io, memory and cpu and even network limits with cgroups and no extra committed ram for the vm. You just give team xyz a login and they run their favorite distribution and software without overhead. If you have a copy on write filesystem you even save more space and with lvm you have easy snapshots and backups. You can put a lot of users on a moderately fast machine this way. Thanks to lxc-attach it is also dead-easy to debug problems for them or install software. I'd love to have this possibility in the future.


Because 1. right now it breaks security 2. its a whole lot more to manage, and thats expensive.

I see the convenience argument, which is why people like docker, but basically adding a whole OS overhead to every process you want to run is basically insane in my view.


Docker doesn't require you to run an entire distro in your container. It's what a lot of people do out of the box because it's convenient and familiar. But as far as docker is concerned your container can be a single static binary in an otherwise empty directory.

There is a growing trend of people building micro-containers with just the bare minimum for their application. Docker is facilitating that trend, not preventing it. If only because it explicitly encourages thinking of containers as application-oriented, not machine oriented.


not saying Docker prevents it but it is hardly widespread. Unless you use Go or a few other languages your toolchsin won't even create static binaries for a start.


Plenty of people run Debian and Gentoo in chroots on top of other linux variants. That is done on Android devices by people who want a more familiar userland to work in and it is done by people for testing and development across distros.


Exactly what security features do you think Docker is providing that LXC isn't?


LXC provides all the features. Except some protection that can at the moment only be provided by AppArmor or another MAC system. I'm not sure what are the LXC defaults are - But I assume that docker uses more restrictive defaults: https://github.com/dotcloud/docker/blob/master/lxc_template....

I'm still learning about LXC so my post regarding security may be inaccurate. I'd just thought I'd share it because a lot of people think it's as secure as a virtual machine. I hope soon it is.


I find the number of people schilling for Docker mindblowing.

"I don't know much about LXC, and I don't know what the defaults are, but I assume that this trivial wrapper around LXC provides more security".


Sorry this was not my intention. I actually prefer LXC to docker myself and did not wanted to shill for anything. I just wanted to point out that of the (possible) security problems that can happen when using LXC docker mitigates most by just not using them: They don't allow mounts, they drop CAP_SYS_ADMIN. I just posted the config file.

It was just a well intended warning - similiar to the warnings in the Ubuntu docs: https://help.ubuntu.com/12.04/serverguide/lxc.html#lxc-secur... and Gentoo: https://wiki.gentoo.org/wiki/LXC#MAJOR_Temporary_Problems_wi...

Here is the default configuration for Ubuntu 13.10 in comparision: https://gist.github.com/anonymous/7550932


A look at docker/LXC security back at the end of August 2013: http://blog.docker.io/2013/08/containers-docker-how-secure-a...




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: