linux-kernel - Re: Chroot bug

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <F23AFB4D-E989-4F06-A256-4D12D852DFA2@mac.com>
Date:	Wed, 26 Sep 2007 01:21:08 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Adrian Bunk <bunk@...nel.org>
Cc:	David Newall <david@...idnewall.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	Bill Davidsen <davidsen@....com>,
	Philipp Marek <philipp@...ek.priv.at>, 7eggert@....de,
	majkls <majkls@...pere.com>, bunk@...tum.de,
	linux-kernel@...r.kernel.org
Subject: Re: Chroot bug

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/