Blogs & Stories

SpiderLabs Blog

Attracting more than a half-million annual readers, this is the security community's go-to destination for technical breakdowns of the latest threats, critical vulnerability disclosures and cutting-edge research.

Chroot support significantly improved in v1.8

Last night I updated the code that provides the internal chroot functionality in mod_security. I am glad to announce version 1.8 will be much more reliable. The tricky part when doing chroot from within a module is that you don't know when to perform the call! Let me explain.

Apache modules are initialised twice. First attempt is a drill: Apache wants to know every module will know how to initialise itself (the configuration is correct, etc). The second attempt is the real thing. Unfortunately, a module does not (and cannot) know if it is being called for the first or for the second time.

The approach I used before is to look at the parent process id. It seemed to me the parent pid was always 1 (init) on second initialisation. As it turns out - I was wrong. In some instances the pid was different, causing mod_security to miss the opportunity to invoke chroot. To resolve this I rewrote the code to use a file on disk as a lock, and now it works great.

While I was doing that I used the opportunity and enhanced the code in other ways, to remove potential weaknesses and provide better error reporting when something goes wrong. The end result is a much more solid implementation. If you want to try it out - download the nightly CVS snapshoot.

Recent SpiderLabs Blog Posts