As far as I am concerned, and most other security professionals I know, chroot is a convenience function, not a security function. Several problem exist with chroot: It does nothing to prevent heap/stack/buffer overflows, format string attacks, etc. Once I can execute code, I can upload more code. It is a real pain in some cases to set up, copying all the neccesary libraries and files into a chroot can be really annoying. It is relatively easy to break out of for an attacker. What can be done to improve the effectiveness of chroots: either create a sepepate partition, or mount a file as a loopback interface, this will allow you to use options such as "nosuid" and "nodev" and to mount the partition read only if possible (this doesn't work for all services of course, some like Bind running secondary zones must be able to write to the filesystem). This also makes distribution of the chroot'ed daemons easier (a single file you copy to the filesystem, and a single line for /etc/fstab). make sure whatever is in the chroot runs as a non root user, and that there aren't any setuid/setgid binaries/etc in the chroot. This may also not be possible, but should be strongly strived for. use better security mechanisms, on FreeBSD there is jail, on Linux there are technologies like WireX's SubDomain, Argus Pitbull LX, and so on. use secure daemons that don't get broken into in the first place where possible. use proxies or intermediaries when you have something like a custom closed source application that may contain security flaws. monitor what programs are doing, periodically run a find/md5sum/tripwire of all the files/etc in the chroot to make sure nothing untoward has happened or been attempted. Kurt Seifried, kurtat_private A15B BEE5 B391 B9AD B0EF AEB0 AD63 0B4E AD56 E574 http://seifried.org/security/ http://www.iDefense.com/
This archive was generated by hypermail 2b30 : Thu May 23 2002 - 21:21:00 PDT