I don't think this should be a discussion of whether chroot is worth using as a security measure. IMHO it should be about allowing Apache users to make a choice whether they will use chroot in this way or not. I am usually an advocate for user choice. For example, I am well aware of the various disadvantages of chroot but I still find some cases where it is useful. In particular, it is very good in preventing (or limiting damage from) automated attacks. It is also very good in significantly raising the effort required to compromise a server after a successful compromise of the web server installation running on it (e.g. through a badly written web application).
For the record, I have regretted including the chroot feature in ModSecurity many times over. Not because of the feature itself (which -- I still think -- is very useful when the circumstances are right) but because of the support I was required to provide on the mailing list over the years. To troubleshoot chroot issues requires a very good understanding of how things work and takes a lot of time. Subtle problems may arise with modules that are not expecting to be cut-off from the filesystem half-way through, or with modules that fork at startup. With this in mind, I have always felt the reluctance of the Apache developers to include support for chroot has more to do with these support issues rather than with any technical reasons. A compromise might be to create a chroot hook and allow module developers to use it. This would shift the support burden somewhat from the core Apache team to those willing to engage the users providing support. Personally, I don't really have a need for the internal chroot feature ever since I discovered the makejail utility (part of Debian, and maybe other systems), which worked really well for me. On the other hand, I am interested in getting Apache to drop certain capabilities (where supported) at startup. I plan to look into it eventually. On Jan 24, 2008 8:33 PM, Ruediger Pluem <[EMAIL PROTECTED]> wrote: > > > On 01/24/2008 04:55 PM, Nick Gearls wrote: > > Yes, chroot could potentially be escaped. > > Although, if you chroot the main process, then you spawn child processes > > under another userid, like in standard Apache config under Unix, I > > expect it to be really very difficult to escape if > > 1. you are not root > > 2. if the only files available are log files and htdocs files (even no > > HTML files in case of a reverse proxy > > Obviously, we could imagine a vulnerability (like a buffer overrun) in > > the child Apache process that would send a signal to the main process to > > use a second vulnerability, but I really find that chrooting Apache > > provides a very good defense. > > It is some kind of defense, but as stated chroot is not really a security tool > (see also http://it.slashdot.org/article.pl?sid=07/09/27/2256235). > Nevertheless, back to your problem. I think there is no gain at all doing > a chroot in the httpd main process which keeps running as root. So IMHO > mod_security is doing the chroot too early by doing it in the post config > hook. > I admit that I do not see any other hook at the moment to do this. > But there is a patch in trunk that does chroot only for the child processes, > just before the userid is switched. I haven't tested this so far, but this > should > work with graceful restarts. Plus: You do not need to keep your logs in the > chroot > jail as the logfiles are opened by the main process. > > Patch: http://svn.apache.org/viewvc?view=rev&revision=611483 > PR: http://issues.apache.org/bugzilla/show_bug.cgi?id=43596 > > Regards > > Rüdiger > > -- Ivan Ristic
