Slashdot Mirror

← Back to Stories (view on slashdot.org)

Using OpenBSD's chrooted Apache

Posted by Hemos on from the learning-what-to-do dept.

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

7 of 101 comments (clear)

  1. Re:Hey - you guys broke my httpd.conf file! by ostiguy · · Score: 4, Informative

    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

  2. Re:site is /.'ed by jolan · · Score: 5, Informative

    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

  3. Recently ? by dnaumov · · Score: 4, Informative

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

  4. Re:site is /.'ed by Anonymous Coward · · Score: 3, Informative

    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.

  5. Re:Performance hit? by QuMa · · Score: 3, Informative

    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)

  6. Breaking a Chroot by elemur · · Score: 3, Informative

    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.

  7. Re:Why is there an "Apache" user? by cras · · Score: 3, Informative
    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.