Date: Thu, 29 May 1997 12:27:24 -0600 From: Warner Losh <imp@village.org> To: Terry Lambert <terry@lambert.org> Cc: dec@phoenix.its.rpi.edu, peter@grendel.IAEhv.nl, mrcpu@cdsnet.net, hackers@freebsd.org Subject: Re: Correct way to chroot for shell account users? Message-ID: <E0wX9v2-0002xM-00@rover.village.org> In-Reply-To: Your message of "Thu, 29 May 1997 10:12:41 PDT." <199705291712.KAA03731@phaeton.artisoft.com> References: <199705291712.KAA03731@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199705291712.KAA03731@phaeton.artisoft.com> Terry Lambert writes: : If the vnode in which the ".." entry is being looked up is : outside the jail, the lookup should return the jail. This : is the main chroot() bug in namei(). You mistakenly assume there is more than one jail. All you have is one pointer, not a nesting. So once you reset that pointer and you have pointers outside the jail, you can still use them. : Your proc's chroot directory will not be changed; this action should : not "land you outside the jail", at least not for the original jail, : though it will take you out of the second jail. Yes it will. fchdir does almost no checking beyond the is this a directory. Again, you have ONE jail, not a nesting of jails. : I guess you are saying that because the ".." is not the jail vnode, : you can traverse up from it and truly be out of the jail. This is, : I think, reducible to an error in the way links are physically : stored on disk as object references instead of reference objects. : If they were stored the other way, it would be possible to store : a single "parent directory" for every reference object. No. The problem is that the test for "Is this inside the jail" is a hard test to make. : Currently, it's possible to store a parent directory for every : directory in the on disk inode, such that it's possible to determine : the location of any directory inode in an FS hierarchy, and *know* : that the current directory is outside the jail, and prohibit reverse : traversals. That this is not done is an error in the UFS directory : handling code, so it affects FFS, MFS, LFS, and EXT2FS, etc.. Yes, but you have to be careful how you do this. The obvious fix breaks many traditional uses of chroot. Directories are special beasts, but in general you can't know if a given file is inside a chroot area or not due to hard links. : It should be noted that only relative forward paths would then work : once outside a jail, so you should still be in the real jail. Any : absolute paths would fail. Once you are outside the jail, you can relative path everything. etc/passwd works just as well :-) : One easier fix would be to disallow keeping fd's referencing DIR type : vnode pointers open across chroot(), but it's useful, and trapped : programs may not realize they are trapped, and rely on it. That would likely be the simplest and safest fix. That would make chroot jails safer. I don't know if that would fix the jailbreak problems completely, but it would be a start. Another "fix" would be to disallow chroot when your root directory is "/" (absolute). : Probably the best fix is to record the hierarchy, as noted above, and : then provide an fchroot() that is allowed out of the hierarchy. I don't understand this. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E0wX9v2-0002xM-00>