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

site is /.'ed

[rf0]

So as I can't comment on the article itself I thought that it might be mentioning that chroots are good but no infalliable. If someone can get root permission inside a chroot you can break out [bpfh.net]

Rus

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

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)

Re:Why BSD?

[Nickus]

AFAIK this is not information everybody can use since this feature only exists on OpenBSD. Apache is patched to chroot() to it's own folder. The -u flag does not exist on standard Apache [apache.org].

Mirror

[SonCorn]

mirror [umr.edu]

Mirror

[rf0]

I've put up a mirror here [65535.net]

Rus

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.

Re:Performance hit?

[Skapare]

Even bind mounts are not secure. They can be remounted read/write, assuming they were read-only to begin with. One way to be sure that can't happen is to have the filesystem so mounted be a loopback to a file which resides on a filesystem which is mounted read/only. That underlying filesystem cannot be changed from inside the chroot (because there is no mount point therein to reference it), so even if the loopback mounted filesystem is made read/write, write attempts should ultimately fail (but even this could be exposed by a bug I don't know about, if one exists).

Modular programming (and dynamically loaded libraries are a form of modularity) just doesn't mix well with security.

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 [nimh.org] which could do that.