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

8 of 101 comments (clear)

  1. slashdotted by mAIsE · · Score: 1, Insightful

    does this PDF have a mirror, or an HTML link ?

  2. Security v. ease of use by unterderbrucke · · Score: 3, Insightful

    Security should always win, but it never does.

    Just my .02 cents.

    1. Re:Security v. ease of use by Ruzty · · Score: 2, Insightful

      Competing is the not the goal. The goal is a highly secure OS capable of doing everything the development team and core user base want it to do. Having others able and desiring to use OpenBSD is a secondary concern driven by a need for funding to continue development.

      OpenBSD does not cater to "Joe User" nor does it claim to. You are correct, Joe User should be using something that gives more direction and simplifies their experience such as RedHat.
      -Rusty

      --
      The Master (Angelo Rossitto) in Mad Max Beyond Thunderdome, "Not shit, energy!"
  3. Re:Hey - you guys broke my httpd.conf file! by greenalbatros · · Score: 2, Insightful


    the relativtly scarce number of IP addresses left

    roll on ipv6

    --
    this sig steers like a cow. and i can prove it
  4. Why BSD? by Anonymous Coward · · Score: 2, Insightful

    (No this isn't a lame BSD troll). Chrooted Apache might be the default on OpenBSD, but this is still information everybody can use. However, judging by the number of posts, as soon you label it 'BSD' it seems most of the (probably Linux-centric) Slashdot readers eyes glaze over, and they never read it (or they post several copies of the 'BSD is dying troll..)

    Yes, it is their loss -- but generally applicable topics that just happen to be demonstrated on a BSD really should not be tagged 'BSD' in the Slashdot topic heading IMHO. They should be tagged according to the topic (Say, Apache, in this case).

  5. Does anyone have a bittorrent of the pdf? by Idimmu+Xul · · Score: 2, Insightful

    Doing something like this in future as standard could conciderably reduce the /. effect!

    --
    The problem with slashdot is that most of its users were bullied and stuffed into lockers as kids!
  6. Re:*BSD is dying by usotsuki · · Score: 1, Insightful

    Opinion: BSD is dying

    Let's put it this way, BSD will not die as long as MacOS X exists. Plus note, it's not about the market share if you can grok the source code!

    -uso.
    BSD r0x0r!

    (Yeah, I know, I'm -1 Offtopic.)

    --
    Dreams, dreams, don't doubt dreams, dreaming children's dreaming dreams. Sailor Moon SS
  7. It's nice but.... by Lagos · · Score: 2, Insightful

    I've been setting up an OpenBSD web server for the past few days now, and had some time to finagle with chroot Apache. I've found it to be a wonderful idea that I've had to disable.

    Why? No fault of OpenBSD, really. Simply that in order to do anything really interesting, I had to disable the chroot of httpd. Take perl scripts, for example: If a CGI script is supposed to be interpreted by /usr/bin/perl (as indicated with #!) it will fail unless you've placed a copy of the perl interpreter in the chroot environment. You can get around this with mod_perl to embed a perl interpreter directly into Apache, but one still will have to preload any shared libraries mod_perl uses (see section four of the paper).

    As another example, PHP's mail() function [which is fairly important, I feel] relies on the presence of sendmail. Sendmail then, must be accessible from the chroot directory in order to work.

    Someone above has commented that you can mount /usr in the chroot environment to solve most of these problems. But of course, as the paper says, the more binaries in the environment, the lower the security, so one must make sure there is no setuid binary available.

    Ultimately, the paper does describe ways around this, basically preloading any shared library your Apache modules might need and populating the chroot jail with any binaries you want for CGI and their shared libraries. This mirroring however requires a good deal of maintenance and waste of space (following OpenBSD partitioning recommendations, /var and /usr will be on seperate partitions so hardlinks won't work. Symlinks can't break out of chroot). At this point, I think a lot of us will be unwilling to sacrifice simplicity (read: stability, maintainability) for this measure of security. The argument that this only affects those who CGI scripts is very correct, but ultimately a trivial point: To do anything interesting (like Slashdot) requires CGI.

    The situation will get better, though, and they'll find a simple elegant maintenance system, as OpenBSD always has. Some things have to change: For example /etc/rc.conf is currently insufficient for preloading libraries. It should have an additional directive called httpd_preload for shared libraries. Also, apachectl may need to be modified or supplemented on OpenBSD.