Re: Chroot bug

From: Kyle Moffett
Date: Wed Sep 26 2007 - 01:21:27 EST

On Sep 25, 2007, at 20:55:51, Adrian Bunk wrote:
On Wed, Sep 26, 2007 at 09:20:54AM +0930, David Newall wrote:
Good call. Though I suppose, since it's used 24x7 to aid security on countless production servers, that security dwarfs testing. Still, debugging, yes that's valid.

Incompetent people implementing security solutions are a real problem.

I don't suppose it makes and difference; whatever the purpose, a chroot that doesn't change the root is buggy.

It does change the root.

But it does not limit what the root user can do after the root was changed.

This is required for most distro installers to work:

*Procedure to install files*
chroot /target
mount -t proc proc /proc
mount -t sysfs sysfs /sys
mount -t tmpfs tmpfs /dev
udevd --daemon
mount /dev/cdrom0 /media/cdrom0
*Load more kernel modules*
*Procedure to configure newly-installed system*
*Do other highly-privileged operations*
*Configure networking and submit installation report*

David, please do tell myself and Adrian how "locking down" chroot() the way you want will avoid letting root break out through any of the above ways?

Hell, after you chroot one could probably just run:
mount --bind /minimal_root /minimal_root
cd /minimal_root
mkdir old
pivot_root . old
cd /old
mkdir old_minimal_root
pivot_root . old_minimal_root
umount /old_minimal_root
rmdir /old_minimal_root
Now, like magic, the entire system is once more accessible.

Alternatively you could:
mount -t proc proc /proc
cat /proc/1/mounts

Either way root can trivially break out of any chroot using FUNDAMENTAL PRIMITIVES that he/she always has access to. If you want to take those away you have to use SELinux or capabilities, in which case you could just take away the CAP_SYS_CHROOT capability in the first place!

Kyle Moffett

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at