From owner-freebsd-security Sat Sep 30 19:16:26 2000 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 710AB37B66D; Sat, 30 Sep 2000 19:16:15 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id WAA47502; Sat, 30 Sep 2000 22:15:57 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 30 Sep 2000 22:15:57 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Cy Schubert - ITSD Open Systems Group Cc: "Brian F. Feldman" , Mike Silbersack , security@FreeBSD.ORG Subject: Re: cvs commit: ports/mail/pine4 Makefile (fwd) In-Reply-To: <200010010146.e911kSk03262@cwsys.cwsent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 30 Sep 2000, Cy Schubert - ITSD Open Systems Group wrote: > In message >, 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