Subject: Re: Escaping a chroot jail
To: None <firstname.lastname@example.org>
From: Steven M. Bellovin <email@example.com>
Date: 07/14/2005 08:42:04
In message <20050714121052.GA5765@panix.com>, Thor Lancelot Simon writes:
>On Wed, Jul 13, 2005 at 06:42:44PM -0400, Steven M. Bellovin wrote:
>> In message <firstname.lastname@example.org>, Michael Richa
>> on writes:
>> >>>>>> "Thor" == Thor Lancelot Simon <email@example.com> writes:
>> > >> and then emulating the file system?
>> > Thor> "Emulating" the file system?
>> > cd /usr/src/sbin/dump; make
>> Or mknod /dev/kmem and overwrite the root vnode pointer in the
>> process's data structures.
>Neither of which works if you run your system at the default security
>level of 1.
>>From my point of view, this "discovery" looks more like "I turned off
>the default security model, and now I can do things that it prohibits!";
>surprise surprise, the default security model was _designed_, and these
>are some of the things it was designed to avoid.
>Rather than gross special-purpose hacks to forbid them even when the
>system's been deliberately configured to be insecure, I suggest:
>1) Running these chrooted processes under systrace
>2) *Never* running chrooted processes as root
>3) Never running daemons as root when any filesystem mounted writable is
> not also mounted nodev.
Right. As I noted in my earlier post, chroot() isn't proof against
As for the default security level of 1 -- for anyone who wants to run
X, that's simply not possible. I understand why, of course, but it
doesn't help with everything else.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb