-----BEGIN PGP SIGNED MESSAGE-----> Date: Fri, 2 May 1997 12:33:00 -0500 > From: "Thomas H. Ptacek" <tqbf@ENTERACT.COM>> On almost all Unix operating systems, having superuser access in a > chroot() jail is still dangerous. In some recent revisions of 4.4BSD > operating systems, root can trivially escape chroot(), as well.I was thinking about possible attacks of this nature last night. For example, suppose somebody gets root inside a chroot''d jail. Then - the attacker can use a device file to access other parts of the physical disk + but the admin has ensured there are no device files in the jail - but the attacker can create one using mknod + but the sysadmin has mounted the partition containing the jail with the nodev option - but the attacker can create and mount a loopback filesystem inside the jail allowing devices to be created and I have no real solution to this, other than, of course, making sure that nobody _does_ get into the machine, even inside a chroot jail. I think a well-thought-out ''ratchet'' security-level system is needed. Yours, - -- Martin Pool, Pharos Business Solutions <m.pool@pharos.com.au> -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: http://www.pharos.com.au/mbp/public_key.txt iQB1AwUBM2qwojr8By6pblTZAQF6igMAjHBF9JIr82Dpb6COfV0Cs0YST/xFEoA1 kFVog0ifUbR0/wXOyo159ItqqYxRhSq7Kz+abtA2tlogAQwUWsmdEWdQp5ALgCTR gcaZi/+TX/SCGB1OqkkdIKYBGprTheBl =4Dxi -----END PGP SIGNATURE----- [mod: There was a discussion between the (ex-) Linux-security moderators, Linus and a few others quite a while ago. The conclusion was that there were enough unpluggable holes in a chrooted environment that it didn''t pay to try to make it root-safe. If you want to find more of these holes, just look for the "suser()" call in your kernel sources, and try to think of a way to exploit that to get out of the "jail". A jail is not root-proof. Make it such that you cannot break root from a normat uid. i.e. all of the above + no setuid programs at all.... -- REW]
[mod: deletia]> + but the sysadmin has mounted the partition containing the jail > with the nodev option > > - but the attacker can create and mount a loopback filesystem inside > the jail allowing devices to be createdGo back to nodev. Mounting a loopback filesystem requires /dev/loop* of type Block, major 7, minor 0 through ??. [mod: Also noted by John Goerzen] [mod: But from reading the source I think you don''t need a /dev entry to remount the partition without the nodev. Moreover you could MAKE the /dev entry and use that if it were necessary. But that is not the issue. The issue is that a chrooted environment is not protected against a root-user inside the chrooted environment. Try int i, mypid =getpid (); for (i=2;i<32768;i++) if (i != mypid) kill (i, 9); Ok. This doesn''t get him out of the chrooted environment, but you can see that having root in a chrooted environment is almost as powerful as non-chrooted. A chrooted environment should be so minimal that the chances of your users becoming root in there are minimal. -- REW] Myles Uyema myles@puck.nether.net
On Sat, 3 May 1997, Myles Uyema wrote:> [mod: deletia] > > + but the sysadmin has mounted the partition containing the jail > > with the nodev option > > > > - but the attacker can create and mount a loopback filesystem inside > > the jail allowing devices to be created > > Go back to nodev. Mounting a loopback filesystem requires /dev/loop* > of type Block, major 7, minor 0 through ??. > > [mod: Also noted by John Goerzen] > > [mod: But from reading the source I think you don''t need a /dev entry > to remount the partition without the nodev. Moreover you could MAKE > the /dev entry and use that if it were necessary. But that is not the > issue. The issue is that a chrooted environment is not protected against > a root-user inside the chrooted environment. Try > int i, mypid =getpid (); > for (i=2;i<32768;i++) > if (i != mypid) kill (i, 9); > Ok. This doesn''t get him out of the chrooted environment, but you can > see that having root in a chrooted environment is almost as powerful > as non-chrooted. A chrooted environment should be so minimal that the > chances of your users becoming root in there are minimal. -- REW]Ok, so it''s been proven that root inside a chroot() is still dangerous; So how about adding the ability to have a whole virtual system? Or at least have some method of denying access to other parts of the system for chroot()''d processes. So, important system calls could be modified thus: int kill(*int pid_to_kill) { if(caller_pid->fs_root != "/") { return(xx); } else { . . . } } or something like that... Note, I''m not a great coder, and have not messed with kernel internals... Don''t know if this is practical or not. But it should be possible to deny certain system calls for chroot()ed root processes. So, if you added some code to mknod(), kill(), exec(), mount() etc you could plug most (if not all) of the problems with chroot() jails. Any thoughts on how practical this is? [mod: We thought about this, and always Linus could come up with another way to break out of the "jail". Feel free to delve in and make a complete kernel patch, but Linus is not easily convinced. Linus'' argument was that since there are thousands of ways to break out, we can''t plug-em-all. Just keep your users inside the jail non-root. --REW]