Slashdot Mirror
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."
Security should always win, but it never does.
.02 cents.
Just my
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
It seems the chrooted Apache configuration in 3.2 is turned on by default, and it prevents cgi mappings from working properly under VirtualHosts directives. I was kind of aggravated; it took a while to figure out what was wrong.
It's documented in the OpenBSD FAQ, but I couldn't pinpoint the problem to OpenBSD specifically (and the error log was mysteriously unhelpful at diagnosing the problem), so I spent quite a while reading up on Apache directives before I figured it out.
It was frustrating, but I know Apache considerably better now, so I guess it was worth it. I agree that security is very admirable, which is why I use OpenBSD in the first place, but I think certain options should be turned off by default, especially if they break common services like VirtualHosts cgi ScriptAliases.
Realistically, are most web servers going to be set up just to host one web site? Or am I the only one who uses VirtualHosts on most of my servers?
Free music from Jack Merlot.
Marc must be such a disappointment to his big brother Steve...
This isn't exactly a recent change, I believe this happened over 6 months ago...
I wonder if this inflicts a performance hit, or more memory is required as a result. I know more disk space is needed, but with the smallest IDEs these days being 40GB, I'm not worried there.
If theres really no performance hit, I wonder if all daemons can be run in seperate chroots, indeed could an inetd be developed that chroots all its daemons. Necessary readonly stuff like libc might be hard-linked rather than copied to save space, unless that would be too much of a security breach.
My very-lazily setup FreeBSD server never gave me problems, and I wouldnt be implementing this in my production server yet, but its nice to HAVE DONE stuff like this to:
(1) boast
(2) print on resume
(3) profit!
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
At home I run the chrooted version under 3.2, and it would be good for doing a standalone, non cgi single site delio. when you start to add more vhosts and what not, you have to make sure that they are in the chroot as well. this isnt allways desireable, especially from an ISP point of view for customers sites, most ISP's I know keep thier customers sites in ~/public_html/ . But it just goes to show that openbsd's whole secure by default persona is in effect.
Gnome wasnt built in a day.
(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).
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!
Neat! I hope FreeBSD and NetBSD use this feature when they all merge.
Looking forward to it. ;)
--
Karma is overrated, whoring is ok.
I've always wondered why the various linux dists don't contain -chroot packages of the various servers that support the chroot environment. Running that way would at least make it a bit more difficult to compromise your system when those inevitable remote exploits are found. If you package them separately, the administrator could choose which ones to run (Though that's not always a good thing.)
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
mirror
What good is a used up world, and how could it be worth having? --Sting
I've put up a mirror here
Rus
Cheap UK and US VPS
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.
The basic problem isn't that Apache runs as "userX" or "userY" or even "root", it's that it ONLY runs as user "apache"!
... logging, etc.
If I have 100 clients using a web server, there's no way for me to protect their stuff from each other. NONE.
It doesn't matter what permissions I apply. I can run PHP in "safe" mode, and apply bandaids to the problem to mitigate this weakness, but it's still there.
Maybe make apache run under xinet.d. (Gee, there goes the "must run as root" problem!) Maybe just have a connection process that connects to an actual daemon for performance reasons.
But Apache should run as the user that owns the site being accessed!
Imagine this in your httpd.conf:
<VirtualHost *>
ServerName www.clientsite.com
ServerAlias clientsite.com
DocumentRoot ~client/html
RunAsUser client
</VirtualHost>
If done right, you should be able to chroot user "client" and have the DocumentRoot be relative within the chrooted file system!
This is a feature of 2.x that is the *only* feature I'm looking forward to. And yet, for some reason, it's on the back burner. It's "unstable", or "in progress". In short, it still sucks.
So we continue to run in an inherently lame-brained environment with security leaks all over the place, with this "unpriveledged user" (typically "nobody") that has more permissions than any other user save root.
Ugh.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
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.
/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).
/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.
/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.
/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.
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
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
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,
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
I kind of like this idea. It moves more towards having a seperate enviornment from the operating system enviornment. Wich i like because i like to keep my http users as far away from the system as possible.
Using grsecurity kernel patch, i can use trusted path execution and take execution privlages away from the apache group, and set its gid = 1005 (or whatever you specified under trusted path execution for the untrusted group in the grsecurity options) and then only give apache execute rights on specific things...(ie pearl, java...etc). Howrever, this way, i only need to give apache execute rights on basically just apache, and run everything else from within the chroot. It makes my life much simplier. Not having to go and find all the intpretures that it needs access to, or the vms, giving them those rights, and then playing around with the directory structure to make sure apache cant just freely roam the system.
It does take more space, but i think its worth it. When i set up a webserver for a client, my biggest worrys are not known exploits, i can write a script to go and patch that for me. Hell in gentoo i write a line of bash and put it in my crontab and i never worry about known exploits agian. What i am more worried about is someone hitting me with a exploit that is not known. So if some sort of bufer overflow happens. At worst, i will lose the http service. But i can have a replication service running if its really a concern. So thats not much of an issue. However, what is an issue is people getting outside of the http service with buffer overflows. the grsecurity kernel patch, enforcing non executable pages and stacks, is nice, and does a good job at stopping buffer overflows, however, this chroot thing i find intergrates nicely into the extra levels of security i put in.