From owner-freebsd-security  Sun Nov  3 19:19:19 1996
Return-Path: owner-security
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id TAA02915
          for security-outgoing; Sun, 3 Nov 1996 19:19:19 -0800 (PST)
Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA02910
          for <freebsd-security@FreeBSD.org>; Sun, 3 Nov 1996 19:19:15 -0800 (PST)
Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.7.5/8.7.3) id TAA10265; Sun, 3 Nov 1996 19:18:38 -0800 (PST)
From: Don Lewis <Don.Lewis@tsc.tdk.com>
Message-Id: <199611040318.TAA10265@salsa.gv.ssi1.com>
Date: Sun, 3 Nov 1996 19:18:36 -0800
In-Reply-To: newton@communica.com.au (Mark Newton)
       "Re: chroot() security" (Nov  3,  4:36am)
X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95)
To: newton@communica.com.au (Mark Newton), Don.Lewis@tsc.tdk.com (Don Lewis)
Subject: Re: chroot() security
Cc: marcs@znep.com, dev@trifecta.com, freebsd-security@FreeBSD.org
Sender: owner-security@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

On Nov 3,  4:36am, Mark Newton wrote:
} Subject: Re: chroot() security
} Don Lewis wrote:
} 
}  > BTW, thanks for mentioning ptrace().  I hadn't thought of that one.
} 
} There's a far more obvious one:  The same data structures and library
} routines which provide "ps" with its ability to find the process table in
} kvm space can permit an attacker with root privileges in a chroot()'ed
} environment to find the process table for the purpose of changing his
} root directory right back to what it used to be by reading and writing
} /dev/kmem.

You're correct, that one is more obvious.  Writes to /dev/kmem can be used
for other evil things as well.  The obvious fixes are to do
one or more of the following:
	Don't put /dev/kmem within reach of the chroot()ed process.

	Turn on securelevel, which I believe prohibits writes to /dev/kmem,
	even by root.

			---  Truck