On 20/08/11 00:42, Stéphane Graber wrote: > On 08/19/2011 03:54 PM, Ulli Horlacher wrote: >> On Fri 2011-08-19 (15:38), Dong-In David Kang wrote: >> >>> We've found out that inside of an LXC instance, root can insert/remove >>> modules of the host. >>> Is it normal? >>> If it is doable, an LXC image may corrupt the host system, which is not >>> good in terms of security. >> Put: >> >> lxc.cap.drop = sys_module >> >> to your LXC container config file. >> And by the way: >> >> lxc.cap.drop = sys_admin >> >> is also a good idea, to prevent that the container root can modify mount >> options, for example set the container filesystem to read-only, which can >> effect ALL containers! > So, for a more generic answer: > > LXC doesn't pretend to be secure when you run stuff as root inside the > container. The proposed solutions above will restrict what root can do > and so may solve a good part of your issues. > > Stuff like "echo b> /proc/sysrq-trigger" will still be possible until > we get the user namespaces (that specific example could be blocked by > some of the security modules though). > > Last week during the LXC/container hackfest in Austin, there's been some > good progress being done on the user namespace and so we can hope to > have these eventually implemented in the kernel. > > Until then, I'd recommend not running untrusted software as root in a > container. It's perfectly safe to run something as a user though. > > For cases where you trust your container user, like development > environments, it's of course fine running stuff as root and I do that > everyday. > > Hope that clarifies the current situation :) > Hi, very interested in this. I've been using LXC for a while but only to segregate functions on my own servers. I am well aware of how delicate the LXC setup is when considering security. For example, unless I customise the init scripts a container can bring down the host. The above options are new to me and I've just added them to my config (not tested yet). I would be interested in reading anything that further describes best practices with respect to security to help me understand and make my host more immune to a container's rogue or mistaken activities.
I come from prior experience with OpenVZ which was more robust in this respect. However I do prefer LXC's simplicity. ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 _______________________________________________ Lxc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxc-users
