ModSecurity Trustwave
This blog has moved! Please update your
bookmarks to http://blog.spiderlabs.com/modsecurity/.

ModSecurity Blog: June 2003

Apache chrooting simplified

I've added a new (and experimental) feature to mod_security (CVS and Apache 1.x only at the moment) that greatly simplifies the process of chrooting in most cases.

Essentially, the chroot call is made from Apache itself, at the very end of the initialisation process. The beauty of it is that Apache performs everything it needs (shared libraries, log files) before the chroot call and that allows you to put only data files into the jail.

I've written a short article here:
http://www.modsecurity.org/documentation/apache-internal-chroot.html

and the link in CVS is (again, only Apache 1.x):
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/mod-security/mod_security/apache1/mod_security.c?rev=1.4

What I have described works perfectly for me but I am interested to hear other opinions (or experiences). If you are interested please give it a try and let me know how you feel.

URL decoding bug fixed

I just fixed a small bug in the URL decoding routine. Apparently, I forgot to add code to convert '+' characters into spaces. It is a great comfort to use regression testing while development. So, this time, before making any changes to the source code I created a test (#31) to test the bug. Then I fixed, and run tests again. Now I know that the bug is fixed, but I also know that the functionality I had before is still there.

Porting mod_security to Windows

With module functioning well on Unix-based platforms I decided to start with the Windows port. The job was straightforward (I only tried with the Apache 1.x version): after creating the makefile and getting all the switches right I was rewarded with a file mod_security.dll.

That's when the trouble started - I couldn't open (from the module) any files or write to them. After spending a lot of time debuggung, I found that there seems to exist a problem with ap_popenf (portable Apache function that opens files) - it returns invalid file handles. After replacing the call to ap_popenf with a call to open, everything worked just fine. This is probably something specific to the version of Windows I have (Windows Me) otherwise other people would have reported it by now (I've found only one such report using Google, with no answer).

So, with the exception of the ap_popenf problem, the module seems to work quite well on Windows, passing all regression tests. The code is in the CVS if you want to give it a try.