Using OpenBSD's chrooted Apache 101
BSD Forums writes "OpenBSD recently changed the mode of operation for the Apache webserver from the normal non-chrooted operation to chrooted operation. This enhances the security of the server on which Apache is run but it imposes a few challenges to the system administrator.
In this article Marc Balmer discusses selected aspects of running a chrooted HTTP daemon and present strategies on how to set up a chrooted environment for more complex applications like database access or using CGI-scripts."
Hey - you guys broke my httpd.conf file! (Score:5, Interesting)
It seems the chrooted Apache configuration in 3.2 is turned on by default, and it prevents cgi mappings from working properly under VirtualHosts directives. I was kind of aggravated; it took a while to figure out what was wrong.
It's documented in the OpenBSD FAQ [openbsd.org], but I couldn't pinpoint the problem to OpenBSD specifically (and the error log was mysteriously unhelpful at diagnosing the problem), so I spent quite a while reading up on Apache directives before I figured it out.
It was frustrating, but I know Apache considerably better now, so I guess it was worth it. I agree that security is very admirable, which is why I use OpenBSD in the first place, but I think certain options should be turned off by default, especially if they break common services like VirtualHosts cgi ScriptAliases.
Realistically, are most web servers going to be set up just to host one web site? Or am I the only one who uses VirtualHosts on most of my servers?
Performance hit? (Score:3, Interesting)
I wonder if this inflicts a performance hit, or more memory is required as a result. I know more disk space is needed, but with the smallest IDEs these days being 40GB, I'm not worried there.
If theres really no performance hit, I wonder if all daemons can be run in seperate chroots, indeed could an inetd be developed that chroots all its daemons. Necessary readonly stuff like libc might be hard-linked rather than copied to save space, unless that would be too much of a security breach.
My very-lazily setup FreeBSD server never gave me problems, and I wouldnt be implementing this in my production server yet, but its nice to HAVE DONE stuff like this to:
(1) boast
(2) print on resume
(3) profit!
Why don't the various Linux Dists... (Score:5, Interesting)
Why is there an "Apache" user? (Score:4, Interesting)
If I have 100 clients using a web server, there's no way for me to protect their stuff from each other. NONE.
It doesn't matter what permissions I apply. I can run PHP in "safe" mode, and apply bandaids to the problem to mitigate this weakness, but it's still there.
Maybe make apache run under xinet.d. (Gee, there goes the "must run as root" problem!) Maybe just have a connection process that connects to an actual daemon for performance reasons.
But Apache should run as the user that owns the site being accessed!
Imagine this in your httpd.conf:
<VirtualHost *>
ServerName www.clientsite.com
ServerAlias clientsite.com
DocumentRoot ~client/html
RunAsUser client
</VirtualHost>
If done right, you should be able to chroot user "client" and have the DocumentRoot be relative within the chrooted file system!
This is a feature of 2.x that is the *only* feature I'm looking forward to. And yet, for some reason, it's on the back burner. It's "unstable", or "in progress". In short, it still sucks.
So we continue to run in an inherently lame-brained environment with security leaks all over the place, with this "unpriveledged user" (typically "nobody") that has more permissions than any other user save root.
Ugh.
Nice for some (Score:2, Interesting)
Using grsecurity kernel patch, i can use trusted path execution and take execution privlages away from the apache group, and set its gid = 1005 (or whatever you specified under trusted path execution for the untrusted group in the grsecurity options) and then only give apache execute rights on specific things...(ie pearl, java...etc). Howrever, this way, i only need to give apache execute rights on basically just apache, and run everything else from within the chroot. It makes my life much simplier. Not having to go and find all the intpretures that it needs access to, or the vms, giving them those rights, and then playing around with the directory structure to make sure apache cant just freely roam the system.
It does take more space, but i think its worth it. When i set up a webserver for a client, my biggest worrys are not known exploits, i can write a script to go and patch that for me. Hell in gentoo i write a line of bash and put it in my crontab and i never worry about known exploits agian. What i am more worried about is someone hitting me with a exploit that is not known. So if some sort of bufer overflow happens. At worst, i will lose the http service. But i can have a replication service running if its really a concern. So thats not much of an issue. However, what is an issue is people getting outside of the http service with buffer overflows. the grsecurity kernel patch, enforcing non executable pages and stacks, is nice, and does a good job at stopping buffer overflows, however, this chroot thing i find intergrates nicely into the extra levels of security i put in.