Subject: Re: Escaping a chroot jail
To: None <tls@rek.tjls.com>
From: Steven M. Bellovin <smb@cs.columbia.edu>
List: tech-security
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 <14566.1121292041@marajade.sandelman.ottawa.on.ca>, Michael Richa
>rds
>> on writes:
>> >
>> >>>>>> "Thor" == Thor Lancelot Simon <tls@rek.tjls.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
root.
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