Date: Sun, 3 Nov 1996 04:36:41 +1030 (CST) From: newton@communica.com.au (Mark Newton) To: Don.Lewis@tsc.tdk.com (Don Lewis) Cc: marcs@znep.com, dev@trifecta.com, freebsd-security@FreeBSD.org Subject: Re: chroot() security Message-ID: <9611021806.AA19481@communica.com.au> In-Reply-To: <199611020401.UAA07806@salsa.gv.ssi1.com> from "Don Lewis" at Nov 1, 96 08:01:03 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Those who are using FreeBSD in a security-conscious environment can
benefit from source code by tweaking it to enforce their sites' security
policies (Werner has already expounded on one example of this). Perhaps
one obvious example of where a source code tweak would assist chroot()'ed
secure spaces is a test which could be added to the setuid() system
call and the filesystem setuid-bit semantics to make uid changes succeed
only if the following conditions are met:
* process executing setuid() is owned by root
we should allow root processes to call setuid() because a) they
can't cause any more damage, and b) "login" and "ftpd" require
setuid() calls to assume the privileges of whoever is using them;
AND
* process executing setuid() is not chroot()'ed
this can be evaluated by comparing the process' root directory against
that of a known system process, such as init (that way you get the
benefit of catching all the chroot()ed child processes as well, without
needing to maintain an "I've been chroot()ed" flag in the proc structure)
Essentially, that'd mean that chrooted processes could never gain the
privileges of another user, including the root user, regardless of
how many setuid programs have been carelessly left behind: Once chroot()
executes, setuid() and the setuid-bit on files both stop working.
Yes, this will break certain executables. No, you probably shouldn't have
those executables in your "secure" area - The whole point of a secure
space is to compartmentalize privileges, so why would you be using it to
provide services which blur privilege boundries?!
Note that I'm not suggesting this as something that should be added to
FreeBSD per se; Rather, I'm suggesting that users of FreeBSD in security-
critical environments can benefit from having kernel sources by taking
the opportunity to "harden" their kernel. Those who make the attempt
will find that once their security policy has been codified in written form,
translating that written form to source code is surprisingly easy
(interdependencies and subtle interrelationships notwithstanding - Be
careful!). The suggestion given above, for example, can be implemented
with just a few lines of C.
- mark
---
Mark Newton Email: newton@communica.com.au
Systems Engineer Phone: +61-8-8373-2523
Communica Systems WWW: http://www.communica.com.au
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9611021806.AA19481>