> 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
This archive was generated by hypermail 2b30 : Thu May 23 2002 - 21:07:25 PDT