Escaping chroots

Sigh. It seems I’m (*1) being called out (*2) for advocating the use of pivot_root over chroot for containers.

Now first off, containers aren’t secure anyway, so this is all kind of moot. If the use of pivot_root over chroot is causing actual problems, we should reconsider. But I couldn’t find any mention of such problems in the post in question.

Nevertheless, chroot *is* escapable. It has nothing to do with ‘your / link not getting updated’. It has to do with the actual (dentry,vfsmount) in kernel-space. I’ll say no more and leave understanding the rest as an exercise for the reader. Of course, before bothering to look, you will want to convince yourself. So grab the source from Set up another rootfs. I had one handy from a container, so I used /var/lib/lxc/natty/rootfs. I copied my executable, called escapechroot, to /var/lib/lxc/natty/rootfs/root. Then I did

root@peqn:/#cd /var/lib/lxc/natty/rootfs
root@peqn:/#chroot .
root@peqn:/#cd .
root@peqn:/# ls /var/lib/lxc/natty
ls: cannot access /var/lib/lxc/natty: No such file or directory
root@peqn:/# /root/escapechroot 
# ls /var/lib/lxc/natty
config	fstab  rootfs

All right, so it *is* escapable. Now go read the kernel code.

(*1) Rudely, with no private communication or chance to show I’m right or admit I’m wrong.

(*2) And being called an author of LXC, which I am not.

This entry was posted in Uncategorized. Bookmark the permalink.

6 Responses to Escaping chroots

  1. corinl says:

    It works the way you do it (only chroot), but it doesn’t work when running it inside the *container*. So containers are secure.

  2. “containers aren’t secure anyway, so this is all kind of moot.”

    Why are containers not safe?

    • s3hh says:

      The most glaring reason is that user namespaces are not yet being enforced at most user id comparisons, including at file system.

      That means that user id X in one user namespace will be deemed owner of a file created by user id X in another user namespace. Toss in root and virtual filesystems like /proc and /sys, and root in a container can do what he likes with the host. MAC can help mitigate this, but user namespaces are still being developed to provide the real solution.

      • s3hh says:

        Another reason, fwiw, is simply that it shares the same kernel as the host. So any exploits in any system calls can likely be exploited by the container to gain privilege and escape the host. The worst offenses are usually in newer system calls, so some hope is being placed in seccomp2 to mitigate this concern.

  3. s3hh says:

    Incidentally, here is some older conversation suggesting that changing chroot to not allow this will never be allowed.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s