Using OpenBSD's chrooted Apache

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."

Comments

Security v. ease of use

[unterderbrucke]

Security should always win, but it never does.

Just my .02 cents.

Hey - you guys broke my httpd.conf file!

[dragonfly_blue]

I admittedly hadn't been paying much attention to the changes, but this one crept up and bit me on the ass last week while I was setting some new web servers for our ISP.

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, 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?

Re:Hey - you guys broke my httpd.conf file!

[ostiguy]

Honestly, this is one of the most touted changes to OpenBSD 3.2 - it was absolutely everywhere on the misc@ list, it is in the FAQ, it is the #3 bullet point under the "What's New" page for the 3.2 release. There is really no excuse for not knowing it was coming, and thus knowing it would be a likely reason for old configs to not work

ostiguy

Marc's Bro

[Anonymous Coward]

Marc must be such a disappointment to his big brother Steve...

Re:site is /.'ed

[jolan]

Yes, if someone gets root, then they can most likely break out of chroot.

Thankfully, under OpenBSD even the apache parent process does not run as root:

www 2376 0.0 0.3 1120 1440 ?? Ss Wed08PM 0:05.56 httpd: parent [chroot /var/www] (httpd)
www 12097 0.0 0.2 1196 1008 ?? I Wed08PM 0:00.02 httpd: child (httpd)

This means "remote root exploit" in Apache becomes "remote www-user-in-chroot exploit" for OpenBSD.

It's a very nice feature. I wrote a document on how to get CVSWeb running within the Apache chroot environment recently. I'm guessing Marc's paper is somewhat similar in nature.

http://marc.theaimsgroup.com/?l=openbsd-misc&m=1 04 900672827459

Recently ?

[dnaumov]

This isn't exactly a recent change, I believe this happened over 6 months ago...

Re:site is /.'ed

[Anonymous Coward]

Apache will bind as root and then drop privs to the named user.

No, it won't. Build it from source, put that in the config, start it as root, and look again. The parent is still running as root.

root 1040 0.0 0.2 2644 156 ? S 2002 0:00 /usr/local/apache/bin/httpd

It needs to bind port 80. OK, so bind the port and then drop privs. It needs to control the logs so that the evil children don't touch it. OK, so change to a different user (other than the network-listeners). Anything but root!

I realize there are other uses for root in Apache. Maybe you want to play games with running CGI programs as different users. That's all well and good, but that's still no reason to default to running as root.

Don't think Apache's priv-sep situation is perfectly sound, either. There was an odd little hole last year that let the unprivileged children whack arbitrary processes with SIGUSR1 through their privileged parent. No root = fewer worries.

Re:Performance hit?

[QuMa]

This is where linux bind mounts come in handy, you can bind mount your /lib and /usr/lib into all your chroots (just make sure they don't contain suids or anything :) ), that way all libraries will only go into memory once, even when used from multiple chroots. (of course you can olso have all your fake roots on the same filesystem and hardlink, but this is a lot nicer)

Why don't the various Linux Dists...

[Greyfox]

I've always wondered why the various linux dists don't contain -chroot packages of the various servers that support the chroot environment. Running that way would at least make it a bit more difficult to compromise your system when those inevitable remote exploits are found. If you package them separately, the administrator could choose which ones to run (Though that's not always a good thing.)

Breaking a Chroot

[elemur]

I couldn't say if it protects against the exact source code listed on that site, but there is a set of kernel security modules which *greatly* protects against these sorts of attacks. The modules are at http://www.grsecurity.org/, and are a wonderful addition to any linux server.

It protects against raw devices, special chroot attacks, UID escalation attacks, many buffer overflows, and other problems. In addition, it adds a whole ACL (Access Control List) system for protecting applications and the overall environment. For a full list of features go to http://www.grsecurity.org/features.php.

I've used this on many different servers with no problems at all. It certainly make you feel better on those servers directly connected to the net.

Why is there an "Apache" user?

[mcrbids]

The basic problem isn't that Apache runs as "userX" or "userY" or even "root", it's that it ONLY runs as user "apache"!

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 ... logging, etc.
</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.

Re:Why is there an "Apache" user?

[cras]

Essentially, by the time you've figured out which vhost the client is requesting, you're bound to a specific httpd process which normally runs as www/nobody or whatever you've configured it as. As those users cannot setuid to the RunAsUser, you can't modify the uid/euid at that stage, only root can do that and you don't want root handling that part of the negotiation!

You use multiple processes then. You can pass the socket file descriptor to another process via UNIX sockets. Or you could just keep proxying the connection to another process if you want portability.

For example you could have a few "connection broker" processes which would parse the initial request. That process would figure out who exactly should be handling the request. Once that's done, it sends very simple request to very small master process which runs as root, consisting of wanted url handler (file, directory, whatever). The root running process verifies the handler is valid, and then either returns error or forwards the connection to the actual handler process (either exec + setuid(), or reuse existing process).

Something like a proper trusted base allowing a user (www) to setuid to other users (vhost1, vhost1 etc) but that requires a version of Unix that supports it; dunno if Trusted Solaris, OpenBSD or SELinux supply that functionality or not.

There's at least kchuid which could do that.