On Tue, 2014-02-11 at 16:39 +0100, Sylvain wrote: > Hi, > > On Mon, Feb 10, 2014 at 09:25:21PM +0000, Ben Hutchings wrote: > > On Mon, 2014-02-10 at 18:40 +0100, Sylvain wrote: > > > On Mon, Feb 10, 2014 at 05:24:17PM +0000, Ben Hutchings wrote: > > > > Are you sure? The point is you should not be able to write to > > > > /sys/kernel/uevent_helper while running as root in the container because > > > > that should not be the same as the 'real' root. Our packages of Linux > > > > 3.12 have user namespaces enabled... but I don't know whether Docker > > > > will use them. > > > > > > Well using 'testing' I ran: > > > aptitude install lxc > > > mount cgroup > > > lxc-create -n secu1 -t debian > > > lxc-start -n secu1 -d > > > lxc-console -n secu1 > > > then I applied the recipe from md. > > > > > > So I may have missed something obvious but I'm pretty sure, yes :/ > > > > I don't believe LXC creates a user namespace by default. You have to > > explicitly configure it. See lxc.conf(5). > > man lxc.conf doesn't say much about adding a namespace :/ > > There is a section about auto-remapping uid/gid, Right, that's an essential part of how user namespaces work. (Capabilities are also scoped.) > but then the system doesn't boot due to permission issues in /dev/pts/. Maybe lxc doesn't yet know how to bootstrap a Debian system for a separate user namespace. Ben. > I searched for some HOWTO on securing lxc, but besides "run everything > as non-root" I didn't find much. -- Ben Hutchings The first rule of tautology club is the first rule of tautology club.
Attachment:
signature.asc
Description: This is a digitally signed message part