March 2006 Archives

I was recently involved with a project where we needed to configure an Apache server that was intended to run multiple web sites/applications. It's a pretty common assignment. To ensure the setup is secure I decided to start by creating a separate user account for each application. This allowed me to correctly configure file permissions to allow Apache to serve the static files directly. To take care of the dynamic content, I configured suEXEC to execute each application's scripts under its own account. (In case you are wondering, this particular server is fast enough to run the scripts as CGIs. But if process creation becomes a bottleneck we can always seamlessly switch to FastCGI to avoid the performance penalty. Nothing to worry about, then.)

SuEXEC is a great tool but I'd love it to be capable of jailing (via the chroot system call) the binaries it executes. However, this feature is not present in the stock version. Having been responsible for the internal chroot feature of ModSecurity, I think I have a pretty good idea of why this is the case: unless you know what you're doing it's pretty easy to break applications with chroot. And if that happens you are going to ask for help... from those that created the feature, right? Of course! As it turns out, chrooting is notoriously difficult to debug remotely and that's why the developers would much rather not deal with it.

But, if do you know your way around feel free to use my suexec chroot patch, which I have just added to the Apache Tools project. But, please, don't write to me if it's not working as you are expecting :)

It's been exactly one year since my book, Apache Security, was published. I was very glad to learn Amazon.com are now enabling book authors to talk to their audience. It is unfortunate this feature did not exist at the time - I would have loved the opportunity to point those looking at this page to the book's web site - http://www.apachesecurity.net.

I have always believed publication is just a first step in the life of a book (a long step in my case, as I spent eight months writing), and that the best stuff comes only after a book has been in use for a year or two. Let's face it, we (the authors) don't know nearly as much as our collective readership does. Therefore I invite you, the reader, to send me your feedback and make the second edition of Apache Security much better!