Re: Chroot bug

[Kyle Moffett <mrmacman_g4@mac.com>]

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