Date: Thu, 29 May 1997 10:12:41 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: imp@village.org (Warner Losh) Cc: terry@lambert.org, 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: <199705291712.KAA03731@phaeton.artisoft.com> In-Reply-To: <E0wX6vy-0002fp-00@rover.village.org> from "Warner Losh" at May 29, 97 09:16:10 am
next in thread | previous in thread | raw e-mail | index | archive | help
> : 1) namei() refusing to traverse ".." from the chroot'ed > : root vnode (this is broken, but then almost all of > : namei() is broken, and no one cares but me...). > > This works because the .. is outside the jail. 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(). > : 4) You don't have to let them have an open fd to the original > : "/" when you throw them in jail. > > Ummm, the "/" I was talking about was the new root (eg /jail in the > non-chroot'd system). You open up /, keep that fd around, then chroot > to someplace else lower in your current tree (eg /jail/xxx in the > non-chrooted case, or /xxx in the chroot'd case). At this point the > fchdir would succeed in landing you outside the jail. 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. 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. 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.. 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. 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. Probably the best fix is to record the hierarchy, as noted above, and then provide an fchroot() that is allowed out of the hierarchy. > 100% correct. However, many people think that a chroot'd environment > is so safe that even root can't climb out. It isn't. If somehow a > user gets root in a chroot'd environment, then your entire machine can > be comporomised. Heh. These people are fools. 8-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705291712.KAA03731>