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."
does this PDF have a mirror, or an HTML link ?
Challenges for the system administrator? Look, each day, billions of people are starving to death worldwide, and Slashdot has an article about the challenge of chrooting a web server or something. Way to go.
All those dead children have you to blame, Taco.
My peave with pdf's is the size, slashdotted in 15secs instead of 45secs.
Dramatic in the slashdot community.
Posting useless rant since 2003.
this was done with the introduction of 3.2. 3.3 will be out shortly. As in May 1st. ._.
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...
I'm not trying again...
This isn't exactly a recent change, I believe this happened over 6 months ago...
I was thinking maybe that was Steve's rebellious teenage son, trying to spite his old man like so many kids do.
I kept the chrooted Apache availible, I just don't ever start it or use it.
Instead, I installed Apache 2.
But considering I'm not doing any mission critical stuff -- I'm really not too worried.
Perhaps all I have to worry about now is getting the speed of my CGI scripts up... But maybe that's just because they're running on a Pentium 100. =)
Rock on OpenBSD!
Location: Mt. Xinu
Spotted this on the list: U.S. Military helps fund Calgary Hacker
try { do() || do_not(); } catch (JediException err) { yoda(err); }
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.
Hi guys.
Just wondering, it seems the OBSD chroot implementation can be broken out of.
I first noticed it here.
And the concept code, which is pretty standard, is here.
Please explain!
(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.
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
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?
you said... root
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.
That good and all, but who can trust a liar? :)
I see you translated my name. *g*
-uso.
Dreams, dreams, don't doubt dreams, dreaming children's dreaming dreams. Sailor Moon SS
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.
For instance, there are several ways to get out of a chrooted environment that have been known for years. Futhermore, the means to correct many of these problems has also been known and available in patch form for years. Yet, all of the afore mentioned UNIXes have failed to make these fixes part of their vanilla kernel trees. Thankfully, there are external patches that fix these problems for some OSes (Linux for instance), but they are not fixed in the default kernels of many distributions, including OpenBSD 3.2, Solaris, FreeBSD and Linux. Here is just a partial list of the known ways of escaping or circumventing a chroot:
double chroot
fchdir
Attaching to shared memory outside of the chroot, that can be fun.
mknod (Oh boy! Make whatever you want inside the chroot!)
And of course, Raw I/O. Nothing stops you from doing that in a chrooted environment.
So, before you assume that chrooting something will add X amount of security to your system, understand that most kernels (Solaris, BSD and Linux) allow for many widely known ways of escaping a chrooted environment and even making the chroot environment irrelevant by still affording an attacker too much control over the box.
Its still admirable to see more services being configured to run in a chrooted environment, but until more kernels are modified to make chroots stronger and to close these holes, the security they create can just be an illusion at best. I'm not advocating that services not be chrooted, but rather that OSes fix many of these issues and that users understand the limitations of chroots as a security tool until that happens.
Python
Bind Apache to (say) port 8765 and NAT the incoming connections from port 80 to there.
/var/www/users/$USERNAME (which useradd or whatever makes), add a group called ap_$USERNAME with each new user, add Apache to the group and chown said directory to $USERNAME:ap_$USERNAME and chmod it g+rx and make it sticky. Don't give Apache write access to anything. You still have a few issues left (if ap_$USERNAME isn't the users' default group, for example), but most of your problems are pushing up daisies. A bit cumbersome for a squillion users, but bearable for up to a few hundred.
And for an encore?
Change your user skeleton so public_html becomes a link to
Got time? Spend some of it coding or testing
True, but they can `break in'. Move the real files to /var but outside the jail(s), put symlinks in their places, and hardlink yourself silly. Of course, I habitually mount /var as nosuid,nodev, so I don't expect much joy from suidperl, for instance. (-:
Got time? Spend some of it coding or testing
Mandrake have begun to.
Got time? Spend some of it coding or testing
Can you translate mine (it's not true by the way)?
Did you mean:
To the University of Maryland Community:
The University of Maryland will shut down in its entirety for Friday, April 11th.
As the deadline for the submission of University's final budget to the state has approached, it has become clear that we are suffering from a large budget shortfall. Because of this, we are forced to shut down the entire campus for a full day. We apologize for the short notice of this cancellation.
Dining services will still be running so that students may eat, and the student union will remain open. However, all classes are cancelled and most professors will not be on campus. A reduced number of shuttles will still be running.
Students may be curious as to why this shortfall has occurred. On March 15th, the Maryland House Appropriations Committee proposed a further $37 million cut to the university system for the 2004 budget year, on top of a $67 million reduction in the current budget. Unfortunately, this proposal was approved, which left us with a drastically reduced budget for 2004. In order to have enough money to continue operations in full in 2004, we must shut do
Thanks to everyone for your patience. Your understanding is appreciated. To the residents of Maryland, be sure to pay careful attention to the candidates you vote for in the upcoming elections, so that we can avoid this situation in the future.
Colonel Cathcart
Director, University Relations
University of Maryland, College Park
********************
This note was authorized for distribution to University of Maryland Community by: Colonel Cathcart, Director University Relations