Messages in this thread | | | From | Kyle Moffett <> | Subject | Re: Chroot bug | Date | Wed, 26 Sep 2007 01:21:08 -0400 |
| |
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 udevtrigger udevsettle 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* *Reboot*
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 mount -t $ROOTFS_FROM_PROC $ROOTDEV_FROM_PROC /
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!
Cheers, Kyle Moffett
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |