The technical explanation of what is unprivileged container is quite good. However, it is not for ordinary PC user. Is there a simple answer when and why people should use unpriviliged containers, and what are their benefits and downsides?

up vote 13 down vote accepted

Running unprivileged containers is the safest way to run containers in a production environment. Containers get bad publicity when it comes to security and one of the reasons is because some users have found that if a user gets root in a container then there is a possibility of gaining root on the host as well. Basically what an unprivileged container does is mask the userid from the host . With unprivileged containers, non root users can create containers and will have and appear in the container as root but will appear as userid 10000 for example on the host (whatever you map the userids as). I recently wrote a blog post on this based on Stephane Graber's blog series on LXC (One of the brilliant minds/lead developers of LXC and someone to definitely follow). I say again, extremely brilliant.

From my blog:

From the container:

lxc-attach -n ubuntu-unprived
root@ubuntu-unprived:/# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 04:48 ?        00:00:00 /sbin/init
root       157     1  0 04:48 ?        00:00:00 upstart-udev-bridge --daemon
root       189     1  0 04:48 ?        00:00:00 /lib/systemd/systemd-udevd --daemon
root       244     1  0 04:48 ?        00:00:00 dhclient -1 -v -pf /run/dhclient.eth0.pid
syslog     290     1  0 04:48 ?        00:00:00 rsyslogd
root       343     1  0 04:48 tty4     00:00:00 /sbin/getty -8 38400 tty4
root       345     1  0 04:48 tty2     00:00:00 /sbin/getty -8 38400 tty2
root       346     1  0 04:48 tty3     00:00:00 /sbin/getty -8 38400 tty3
root       359     1  0 04:48 ?        00:00:00 cron
root       386     1  0 04:48 console  00:00:00 /sbin/getty -8 38400 console
root       389     1  0 04:48 tty1     00:00:00 /sbin/getty -8 38400 tty1
root       408     1  0 04:48 ?        00:00:00 upstart-socket-bridge --daemon
root       409     1  0 04:48 ?        00:00:00 upstart-file-bridge --daemon
root       431     0  0 05:06 ?        00:00:00 /bin/bash
root       434   431  0 05:06 ?        00:00:00 ps -ef

From the host:

lxc-info -Ssip --name ubuntu-unprived
State:          RUNNING
PID:            3104
IP:             10.1.0.107
CPU use:        2.27 seconds
BlkIO use:      680.00 KiB
Memory use:     7.24 MiB
Link:           vethJ1Y7TG
TX bytes:      7.30 KiB
RX bytes:      46.21 KiB
Total bytes:   53.51 KiB

ps -ef | grep 3104
100000    3104  3067  0 Nov11 ?        00:00:00 /sbin/init
100000    3330  3104  0 Nov11 ?        00:00:00 upstart-udev-bridge --daemon
100000    3362  3104  0 Nov11 ?        00:00:00 /lib/systemd/systemd-udevd --daemon
100000    3417  3104  0 Nov11 ?        00:00:00 dhclient -1 -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0
100102    3463  3104  0 Nov11 ?        00:00:00 rsyslogd
100000    3516  3104  0 Nov11 pts/8    00:00:00 /sbin/getty -8 38400 tty4
100000    3518  3104  0 Nov11 pts/6    00:00:00 /sbin/getty -8 38400 tty2
100000    3519  3104  0 Nov11 pts/7    00:00:00 /sbin/getty -8 38400 tty3
100000    3532  3104  0 Nov11 ?        00:00:00 cron
100000    3559  3104  0 Nov11 pts/9    00:00:00 /sbin/getty -8 38400 console
100000    3562  3104  0 Nov11 pts/5    00:00:00 /sbin/getty -8 38400 tty1
100000    3581  3104  0 Nov11 ?        00:00:00 upstart-socket-bridge --daemon
100000    3582  3104  0 Nov11 ?        00:00:00 upstart-file-bridge --daemon
lxc       3780  1518  0 00:10 pts/4    00:00:00 grep --color=auto 3104

As you can see processes are running inside the container as root but are not appearing as root but as 100000 from the host.

So to sum up: Benefits - added security and added isolation for security. Downside - A little confusing to wrap your head around at first and not for the novice user.

  • 2
    So, if I understand it correctly, containers are not 100% secure by themselves. No matter which container you run, there is a chance that beast can escape. And it is only here, when type of container becomes important. For privileged containers the beast will wild run under root, planting rootkits and munching valuable SSL keys. For unprivileged it will be limited only to the user account that created container, right? Stealing his SSH keys etc. Is that really more secure? Can it be explained with a picture of four nested boxes? – anatoly techtonik Jan 27 '15 at 16:51
  • 2
    In short, Containers themselves right out of the box are not secure for production use. Treat your LXC environment as you would any other Linux environment. You wouldn't leave your Linux box wide open either right?! Yes your container would be limited only to which the user account is mapped to. Check out Graber's post on unprived conatiners: I think the biggest issue is being able to exploit the kernel and syscalls because every container shares the same kernel. There are several ways to enhance security through cgroups and other applications like selinux, apparmor and seccomp and more. – geekbass Jan 27 '15 at 20:34
  • 3
    Stéphane Graber - stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers – geekbass Jan 27 '15 at 20:37
  • So, create a separate limited user for running containers. Seems fair. I accept this as the answer. Thanks. – anatoly techtonik Jan 27 '15 at 21:03

They are very valuable tools for testing, sandboxing and encapsulation. Want a webserver to be safely locked in its own working environment, unable to access sensitive private files? Use a container. You have an application that requires old versions of libraries, and specific configuration files, incompatible with other applications? Also a container. It's basically chroot done right. It allows you to maintain services separate enough so maintaining each of them is much easier, and they can be moved or copied to another machine without having to disturb the existing system.

The downside is that you need to remember the namespace for almost everything is local to the container. You have to be aware of where you are, and communication between containers is not trivial. It's a good idea when you need modularity, but don't want the overhead of virtual machines, and the things you keep in containers are really not related much.

For an "ordinary" user, you can use containers to use a single machine for two people while keeping them as though they are on completely different machines. Roommates, for instance.

  • 3
    While a good human description of what containers are for, this still doesn't explain the difference between privileged and unprivileged ones. – anatoly techtonik Jan 28 '15 at 3:37

Well, with a shared kernel, despite it increasing the requirements of the adversary to break free in some ways (or rather; it helps limiting the attack surface), unprivileged containers are still not completely isolated from straight hacks which gain host root, despite this.

For that reason, it is a bit of a wrong assumption/claim. Having said that, the level of technial aptitude in many users across the internet will still run inet services, in a multitude of ways which they aren't really technically capable of, so hey. :)

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.