5

I have some device (say /dev/sda1) mounted at /home/user1. I also have a full Linux system under /tmp/chroot, and the directory /tmp/chroot/home contains only one directory named user2.

If I chroot inside /tmp/chroot, mount /dev, /sys and /proc there and issue the mount command (or cat /proc/mounts), I can still see /dev/sda1 mounted at /home/user1 whereas the directory /home/user1 does not even exist anymore (in the chroot).

I also tried with jchroot instead of chroot (this is a program with an interface similar to chroot but creating a new mount namespace and a new PID namespace), but the results are the same.

Is this normal behaviour? It sounds weird that I can access information about mount points outside the chroot.
Is there a way to make them disappear from /proc/mounts?

Improve this question

2 Answers 2

Reset to default
5

This is the expected behavior within a chroot. The chroot really only changes what the process sees as the root directory of the filesystem '/' to a different directory than what was mounted as '/' at boot time. Said process still has the same global access to the kernel itself, just not to the '/' file system.

The kernel does not do any fixups or emulation to /proc or devices to make the chrooted process believe the chroot is 'real'. As a side effect of this, any process running as a superuser in a chroot can trivially break out of the chroot in many ways (eg, mount /dev and mount /dev/sdaX where the real root is, or even just mknod a new device entry and mount using that-- the kernel doesn't care). The chrooted process could even insmod a device driver and do whatever it likes...

If you are looking to 'trick' a process into thinking its running under a different system than it is currently running or to provide a layer of security, chroot is probably the wrong technology, I'd recommend looking into User Mode Linux or possibly Linux Containers

Improve this answer
1
  • Would it work with lxc? I thought that Linux Containers was nothing more than chroot + mount namespace + PID namespace + a few others namespaces. Commented Aug 24, 2011 at 11:14
3

Yes, you would need to use "unshare" instead (or as well as) chroot; chroot ONLY changes the root directory of the process. While it's difficult in practice to get to anything which is above it, there are many ways to break out. It's not a jail.

There are some tools which do this, such as "lxc" (Linux containers)

Improve this answer
2
  • As far as I can tell, the unshare command will not do anything more than jchroot, it just uses the mount namespaces features, and I already checked (with jchroot) that this does not work any better. Commented Aug 23, 2011 at 23:23
  • @Guillaume Brunerie: You should be able to umount the offending mountpoints within the new mount namespace, though (which will remove them from /proc/mounts for that namespace). Commented Aug 24, 2011 at 3:18

You must log in to answer this question.