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

12 of 101 comments (clear)

  1. site is /.'ed by rf0 · · Score: 2, Informative

    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

    Rus

    --
    Cheap UK and US VPS
    1. 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

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

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

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

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

  4. 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)

  5. Re:Why BSD? by Nickus · · Score: 2, Informative

    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.

  6. Mirror by SonCorn · · Score: 2, Informative

    mirror

    --
    What good is a used up world, and how could it be worth having? --Sting
  7. Mirror by rf0 · · Score: 2, Informative

    I've put up a mirror here

    Rus

    --
    Cheap UK and US VPS
  8. 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.

  9. Re:Performance hit? by Skapare · · Score: 2, Informative

    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.

    --
    now we need to go OSS in diesel cars
  10. 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.