Date: Sat, 30 Sep 2000 22:15:57 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> Cc: "Brian F. Feldman" <green@FreeBSD.ORG>, Mike Silbersack <silby@silby.com>, security@FreeBSD.ORG Subject: Re: cvs commit: ports/mail/pine4 Makefile (fwd) Message-ID: <Pine.NEB.3.96L.1000930220916.44353C-100000@fledge.watson.org> In-Reply-To: <200010010146.e911kSk03262@cwsys.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 30 Sep 2000, Cy Schubert - ITSD Open Systems Group wrote: > In message <Pine.NEB.3.96L.1000930183027.44353A-100000@fledge.watson.org > >, Robe > rt Watson writes: > > > > Using only chroot() and the ability to execute arbitrary code, it is easy > > to break out of a user-initiated sandbox if any processes owned by the > > same user are present outside of the sandbox. > > The last time I tried the chroot() breakout code under FreeBSD-4 it > didn't work. I assume that someone had fixed FreeBSD. There are so many ways to break out of a chroot(8), there are almost too many to count, especially if you have privilege. The way I was referring to was to use ptrace() to control processes with a different process file lookup root, hence the requirement that they be owned by the same user, and my comment that in order to do it right, you need a more general MAC mechanism. chroot() simply changes the file system namespace (not necessarily even restricting it), it doesn't block the numerous other mechanisms for IPC in the system. jail(8) makes a fairly decent effort to limit access to privilege allowing the chroot() to be broken, and also limit IPC so as to prevent unwanted communication between processes in a jail() and outside of it. Brian's patches attempt to address some of the more common criticisms of chroot() by allowing the administrator to determine that an un-privileged chroot() will prevent setuid/setgid binaries from being executed (or at least, the mode bits being active), which counteracts some of the common user chroot() attacks, such as redoing the namespace so that setuid/setgid binaries which depend on a constant namespace misbehave. For example, an easy way to leverage the normal chroot(8) if it is permitted for unprivileged users is to hard link /usr/bin/su to /usr/tmp, create a custom /usr/tmp/etc with password files, et al, chroot() to /usr/tmp, and then use su to gain privilege. Brian's patches to not attempt to address breaking the chroot() through means other than the traditional file system namespace, as that's a much harder problem to address. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000930220916.44353C-100000>