Consider using unpriviledged containers

[raneq]

Running containers as root was the only option some time ago, but since a while ago a safer option is available. This would add some steps to this script, but could do less assumptions of the host machine and improve security.

As they say in the docs:

should something go very wrong and an attacker manages to escape the container, they'll find themselves with about as many rights as a nobody user.

However, this has some drawbacks:

Unfortunately this also means that the following common operations aren't allowed:

mounting most of filesystems
creating device nodes
any operation against a uid/gid outside of the mapped set

Because of that, most distribution templates simply won't work with those. Instead you should use the "download" template which will provide you with pre-built images of the distributions that are known to work in such an environment.

There is also a good how-to in the debian wiki.

[raneq]

More drawbacks: lxc-autostart at boot does not start unprivileged containers, at least in Debian Stretch.

When systemd starts the lxc service, the lxc service calls lxc-autostart. But lxc-autostart is called as root, so even if you have “lxc.start.auto = 1” in your container config, your unprivileged container isn’t started.

If you login as the user that owns the container, and run lxc-autostart as that user, your container will start, assuming you did set its config to autostart.

source https://forum.level1techs.com/t/lxc-unprivileged-autostart-in-debian-stretch/123709/3

[enricostano]

Yep, we can look into it. In any case keep in mind that this is just for development purposes, nothing that will be used in production.

[enricostano]

@raneq can we close this issue? We're not using devenv in a production environment.

[raneq]

@raneq can we close this issue? We're not using devenv in a production environment.

I didn't remember this was open. We already dismissed it because of your point.