Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Steve Bremer (stevebnebcoinc.com)
Date: Wed May 22 2002 - 19:20:48 CDT
> However, if I want to use your box to attack another box then the lack
> of binaries won't stop me - I'll just make my exploit download my own
> and store then in /tmp (or /logs or something) in the chroot jail.
Perhaps one way around this is to put the chroot jail on it's own file
system. Assign it to a file system with very little free space left to
prevent intruders from trying to store their software there. If you
don't have a free partition left, create a file system in a file and
loopback mount it.
Of course, depending upon what files you have in the chroot jail,
someone may be able to free up enough space by deleting your
files. Using the immutable bit on files should prevent this from
happening as long as the attacker never attains root privilege. But
if he/she does get root, this is all in vein anyway.
Of course, you may have problems with log files. However,
syslogd can be told to listen on an additional device such as the
/dev/log device within the chroot jail. That way the service that is
chroot'd logs to your normal system logs outside of the chroot jail.
On the other hand, because syslog has had problems in the past,
someone might be able to take advantage of a vulnerability in
syslog to break out, theoretically speaking. If you're worried about
that possibility, try using the syslog that comes with Owl Linux. It
chroots itself and drops privileges after opening the necessary files.
I haven't tried all of these suggestions, but I have created chroot
jails on loopback mounted file systems with minimal free space in
order to prevent someone from uploading programs/files to the
I'm curious to hear what others think about these suggestions.