Comment 9 for bug 1639345

@Christian Brauner (comment #7):

> can you please explain the details of your exploit in more detail; e.g. how you were preparing fd=7.

The fd=7 is just the directory-fd pointing to /proc/[pid] on the HOST. It seems that lxc-attach keeps it open to access the host side /proc/[pid] resources even after setns().

If you do a "strace -s256 -f screen lxc-attch -n name" (without your self-ptrace patch), you can find following calls:

# This is still in initns, here the fd=7 is created. The number might be different for SSH logins, screen session, bash vs other shell ....
[pid 1712] open("/proc", O_RDONLY|O_DIRECTORY) = 7
... immediately afterwards
[pid 1712] open("/proc/1632/ns/user", O_RDONLY|O_CLOEXEC) = 9
[pid 1712] open("/proc/1632/ns/mnt", O_RDONLY|O_CLOEXEC) = 10
...
# now use the ns-fds, thus changing the root to reside in container
[pid 1712] setns(9, 0) = 0
[pid 1712] close(9) = 0
[pid 1712] setns(10, 0) = 0
...
# later on after changing to guest-ns uid=0, the fd is used.
[pid 1713] openat(7, "self/attr/current", O_RDWR) = 8
[pid 1713] write(8, "changeprofile lxc-container-default-cgns\0", 41) = 41

The ptrace part just makes lxc-attach close the wrong file descriptor (not 7) before executing the guest command (/bin/sh), thus giving access to the open fd=7 via guest proc filesystem.

A full, failsafe exploit should try to infere the correct fd-number to search for or use the fixed stack offsets, they seem to be quite reliable.