From owner-freebsd-hackers Thu May 29 07:59:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA17781 for hackers-outgoing; Thu, 29 May 1997 07:59:46 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id HAA17776 for ; Thu, 29 May 1997 07:59:44 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id HAA03526; Thu, 29 May 1997 07:56:26 -0700 From: Terry Lambert Message-Id: <199705291456.HAA03526@phaeton.artisoft.com> Subject: Re: Correct way to chroot for shell account users? To: imp@village.org (Warner Losh) Date: Thu, 29 May 1997 07:56:26 -0700 (MST) Cc: dec@phoenix.its.rpi.edu, peter@grendel.IAEhv.nl, mrcpu@cdsnet.net, hackers@FreeBSD.ORG In-Reply-To: from "Warner Losh" at May 28, 97 10:57:47 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > : Could someone give me some simple details of how to break out of a chroot > : 'jail' (without relying on kernfs or raw devices), I have heard of this > : before, but no one has given me a theory or code of how to do it. > > Basically, and this has been posted in many places, you get a handle > on something outside the jail. You do this by basically opening '/', > mkdir xxx, chroot xxx, then fchdir to the old '/' and then chdir '..'. > There are things that can be done in the kernel, but they are either > very expensive or very hard to get right (and not break anything) or > both. > > A simple fix is to disallow a chroot when someone has already been > chroot'd. This break symetry, but doesn't completely solve the > problem because there are many other ways out (that aren't on the top > of my head). > > Hmmm, writing this up, I realized what the ln way was. If you are in > a chroot jail, you mkdir xxx; ln xxx/yyy /; chroot xxx; cd yyy; cd > .. ; ... and you are out. However, the ln step is no longer allowed > since it is hard linking directories together, which is bad for other > reasons. I really don't see how either of these could possibly work, given: 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...). 2) The chroot() call takes a path, which namei() will look up relative 3) The link() system call in /sys/kern/vfs_syscalls.c has code to prevent hard links on directories: if (vp->v_type == VDIR) error = EPERM; /* POSIX */ Not even root can do the hard link your method requires. 4) You don't have to let them have an open fd to the original "/" when you throw them in jail. 5) Calling chroot(2) is restricted to the superuser anyway, and only an idiot would try to put a root user in a chroot jail anyway (or put an ordinary user in a chroot jail with suid/sgid binaries). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.