Date: Fri, 1 Nov 1996 20:01:03 -0800 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Marc Slemko <marcs@znep.com>, Dev Chanchani <dev@trifecta.com> Cc: freebsd-security@freebsd.org Subject: Re: chroot() security Message-ID: <199611020401.UAA07806@salsa.gv.ssi1.com> In-Reply-To: Marc Slemko <marcs@znep.com> "Re: chroot() security" (Nov 1, 6:29pm)
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 1, 6:29pm, Marc Slemko wrote: } Subject: Re: chroot() security } On Fri, 1 Nov 1996, Dev Chanchani wrote: } > Basically, how can someone get out of a chroot()'ed environment is they } > get root? } } Many, many ways. } They can do whatever they want; it may take some effort, but not that } much. Simply getting root does not automatically give access to files } outside the chrooted environment, but it is easy enough to get once you } have root. For example, from inside the chrooted environment create } /dev/sd0a or whatever the root partition is and then you have full access } to the raw device. It isn't as easy as just mounting it, since it is } already mounted once, but it is quite easy to do a few minor edits to get } root outside the chrooted environment. Things like /dev/mem and /dev/kmem } give you access to all the memory on the system. The user can attach a } debugger to a process running outside the chrooted environment, then } modify it to give them access. The list goes on and on. You can add various checks to the kernel to keep chroot()ed processes from doing a lot of these things, but there is one deadly exploit that someone posted to this list back in September. By the clever use of chroot() and chdir(), it is possible for a root process to waltz out of a chroot()ed environment. I don't know of a clean way of plugging that hole. BTW, thanks for mentioning ptrace(). I hadn't thought of that one. --- Truck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611020401.UAA07806>