Linux Privilege Escalation - LXD


Anyone else facing the same problem??

1 Like

Hello. I had the very same problem, you may try this at the end - spoiler:

lxc exec privesc /bin/sh


Thanks a lot man. I did the mistake to try as “/bin/” but i didn’t even thought about trying just sh

1 Like

I guess I don’t understand what you are trying to do with that LXD container so maybe my response below is off-base in which case I appologize.

Couple things i’d mention if the purpose is to prove “privilege escalation:”

1 - The LXD Default Container Profile only creates “unprivileged” Containers
2 - You picture shows that you created your container and specified it to be a Privileged

-c security.privileged=true

3 - *On any LXD Linux Host some Admin with sudo privileges had to have added you to the LXD Group so you would be permitted to create/launch/stop/delete LXD Containers. So there is trust involved just as if you were a System Admin and decided someone should have “sudo” privileges.

Per LXD Documentation

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:

lxc config set c1 security.privileged true

Note however that in this case the root user in the container is the root user on the host.


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.


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

So if you are trying to test LXD Privilege Escalation try doing it with an Unprivileged LXD Container.

Alpine does not support /bin/bash it does however support /bin/sh

1 Like