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

slashdotted

[mAIsE]

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

Security v. ease of use

[unterderbrucke]

Security should always win, but it never does.

Just my .02 cents.

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

[greenalbatros]

the relativtly scarce number of IP addresses left


roll on ipv6

Why BSD?

[Anonymous Coward]

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

Does anyone have a bittorrent of the pdf?

[Idimmu Xul]

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

Re:*BSD is dying

[usotsuki]

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

Re:Security v. ease of use

[Ruzty]

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

It's nice but....

[Lagos]

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.