Hello,
Anyone else facing the same problem??
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/bash.sh” but i didn’t even thought about trying just sh
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
Container:
-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.
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.
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 theraw.apparmor
configuration key.
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
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
hi, do you know where is the file flag.txt is located i managed to escalate but i cant find the file
the flag is located at /mnt/root/root/flag.txt