Making containers safer [LWN.net]

Making containers safer

Posted Aug 21, 2019 15:34 UTC (Wed) by stgraber (subscriber, #57367)
Parent article: Making containers safer

For anyone interested in playing with LXD, we have an online demo available here: https://linuxcontainers.org/lxd/try-it/

This gives you 30min of root access to a LXD container that itself has LXD installed.
That way you can play with LXD, start containers and explore some of the basic features without ever installing anything locally.
There is a small tutorial that you can follow which will get you through some of the basics, or you can just play with it whichever way you want instead.

to post comments

Making containers safer

Posted Aug 21, 2019 15:45 UTC (Wed) by epa (subscriber, #39769) [Link] (5 responses)

It's excellent that LXD containers can be nested. That would have been my first question about them.

Is it possible to use LXD as a non-privileged user, or do you need to be root to set it up?

Making containers safer

Posted Aug 21, 2019 16:45 UTC (Wed) by stgraber (subscriber, #57367) [Link]

The LXD daemon requires root privileges. That's effectively needed by a lot of features to the point where adding logic to handle unprivileged daemon everywhere would have been very impractical (we did at the very beginning).
Some of those features involve network/storage management, system call interception in containers, checkpoint/restore, injection of uevents, mounts and devices inside containers, ...

Now that being said, LXD can absolutely work nested inside an unprivileged container, which is the very setup we do on that demo server. In such an environment, LXD effectively runs as a root inside a user namespace, so as a globally unprivileged user which does have privileges against the namespaces tied to that user namespace.

It's worth pointing out that has a result of our daemon running as root, we do take any communication between the container and daemon very seriously as flaws there would be disastrous from a security standpoint (potentially allowing escape from an unprivileged container). The only such interface is a /dev/lxd REST API that we expose containers to fetch properties from the daemon. This interface can be disabled through a configuration key, at which point the container would no longer have any way to interact with the daemon that spawned it.

Making containers safer

Posted Aug 22, 2019 4:49 UTC (Thu) by skissane (subscriber, #38675) [Link] (1 responses)

> It's excellent that LXD containers can be nested. That would have been my first question about them.

I tried starting a container inside a container using tryit. I couldn't get it to work, lots of permissions issues. (I don't really know what I am doing though, maybe I used the wrong steps or config options.)

Making containers safer

Posted Aug 22, 2019 18:01 UTC (Thu) by stgraber (subscriber, #57367) [Link]

lxc launch ubuntu:18.04 c1 -c security.nesting=true
lxc exec c1 bash
  lxd init
  lxc launch images:alpine/edge a1
  lxc list

This should work fine. During "lxd init", the one thing that you'll need to pick which isn't already the default value is the IPv4 subnet. In my test, I used "192.168.0.1/24" which worked fine.

The reason for this, is that the try-it environment has a subnet of 10.0.0.0/8 which prevents LXD from automatically picking an unused subnet in that range. Manually specifying one is therefore required.

PS: Note that the try-it session is already itself a LXD container, so doing the above actually gets you a nested, nested container :)

Making containers safer

Posted Aug 26, 2019 16:20 UTC (Mon) by gradey (guest, #133690) [Link] (1 responses)

What's a use case for nested containers? A traditional docker setup has you create a container per application. So if I have app x and y, then docker creates two containers. With nested containers would it make sense to have one "host" container that then creates nested containers for apps x and y? What's advantageous about this?

Making containers safer

Posted Aug 26, 2019 20:02 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

CI builds usually occur within containers. How is one supposed to CI their `Dockerfile` builds inside of such an environment if nesting isn't supported?

> With nested containers would it make sense to have one "host" container that then creates nested containers for apps x and y?

It means that my application can work from within a container no differently than outside a container.