Ubuntu Server Guide

UID mappings and Privileged containers
By default, LXD creates unprivileged containers. This means that root in the container is a non-root UID
on the host. It is privileged against the resources owned by the container, but unprivileged with respect
to the host, making root in a container roughly equivalent to an unprivileged user on the host. (The main
exception is the increased attack surface exposed through the system call interface)
Briefly, in an unprivileged container, 65536 UIDs are ‘shifted’ into the container. For instance, UID 0 in the
container may be 100000 on the host, UID 1 in the container is 100001, etc, up to 165535. The starting
value for UIDs and GIDs, respectively, is determined by the ‘root’ entry the /etc/subuid and /etc/subgid
files. (See the subuid(5) man page.)
It is possible to request a container to run without a UID mapping by setting the security . privileged flag
to true:
l x c c o n f i g s e t c1 s e c u r i t y . p r i v i l e g e d t r u e
Note however that in this case the root user in the container is the root user on the host.
Apparmor
LXD confines containers by default with an apparmor profile which protects containers from each other
and the host from containers. For instance this will prevent root in one container from signaling root in
another container, even though they have the same uid mapping. It also prevents writing to dangerous,
un-namespaced files such as many sysctls and /proc/sysrq−trigger.
If the apparmor policy for a container needs to be modified for a container c1, specific apparmor policy lines
can be added in the raw.apparmor configuration key.
117

---

Seccomp
All containers are confined by a default seccomp policy. This policy prevents some dangerous actions such
as forced umounts, kernel module loading and unloading, kexec, and the open_by_handle_at system call.
The seccomp configuration cannot be modified, however a completely different seccomp policy – or none –
can be requested using raw.lxc (see below).