RE: OT? Are chroots immune to buffer overflows?

["Steve Bremer" <steveb () nebcoinc com>]

> 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 
chroot jail.

I'm curious to hear what others think about these suggestions.

Steve Bremer