Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software Apache BSD

Using OpenBSD's chrooted Apache 101

Posted by Hemos 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."
This discussion has been archived. No new comments can be posted.

Using OpenBSD's chrooted Apache More

Using OpenBSD's chrooted Apache

Comments Filter:

  • slashdotted (Score:1, Insightful)

    by mAIsE ( 548 )
    does this PDF have a mirror, or an HTML link ?

  • My peave with pdf's is the size, slashdotted in 15secs instead of 45secs.

    Dramatic in the slashdot community.
  • this was done with the introduction of 3.2. 3.3 will be out shortly. As in May 1st. ._.

  • Security v. ease of use (Score:3, Insightful)

    by unterderbrucke ( 628741 ) <unterderbrucke@yahoo.com> on Monday April 07, 2003 @08:51AM (#5678153)
    Security should always win, but it never does.

    Just my .02 cents.
    • Now I'd have thought that in this case, it is security that is winning out over the ease of use of having older httpd.conf files work.
    • "Security should always win, but it never does."

      If that were really true then why don't you shut down you computer? It would certainly make it much more secure at the expense of ease of use?!
    • I agree with that right up to the point where the difficulty in use prevents an administrator from doing the right thing.
      Security should be easy to implement and difficult to circumvent.
    • Security is important and all, but the choice between security and usability isn't an absolute. The greatest security for my web site would be to burn it onto a CD and chroot the server to that CD. That's not practical though when I'm using the website to demonstrate and sell content management systems. So I need to compromise my security a bit to allow the server and the CGI programs that it spawns to write to certain files or directories. It's less secure than my burned-on-a-cd option, but fits my nee
    • "Just my .02 cents."

      That's not a lot of cents. I really love it when people go as far as to put

      "Just my USD $0.02"

      Wankers.

  • site is /.'ed (Score:3, Informative)

    by rf0 ( 159958 ) <rghf@fsck.me.uk> on Monday April 07, 2003 @08:56AM (#5678171) Homepage
    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 [bpfh.net]

    Rus

    • Re:site is /.'ed (Score:5, Informative)

      by jolan ( 187075 ) on Monday April 07, 2003 @09:17AM (#5678265)
      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

    • If someone can get root permission inside a chroot you can break out [bpfh.net]

      Sure, but then again who in their right mind runs a web browser, ftp server, cvs site, news server, name server or practically any server as root anymore?

    • Breaking a Chroot (Score:4, Informative)

      by elemur ( 7613 ) on Monday April 07, 2003 @11:44AM (#5679237)
      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 site reports that the code to break out works on Solaris and Linux. No mention is made of OpenBSD. It does say that FreeBSD is not vulnerable to the attack.

  • Hey - you guys broke my httpd.conf file! (Score:5, Interesting)

    by dragonfly_blue ( 101697 ) on Monday April 07, 2003 @08:56AM (#5678176) Homepage
    I admittedly hadn't been paying much attention to the changes, but this one crept up and bit me on the ass last week while I was setting some new web servers for our ISP.

    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 [openbsd.org], 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?

  • Marc's Bro (Score:3, Funny)

    by Anonymous Coward on Monday April 07, 2003 @09:04AM (#5678216)
    Marc must be such a disappointment to his big brother Steve...
  • But due to the really slow down load, and then then file being corrupt (according to my pdf reader).

    I'm not trying again...

  • Recently ? (Score:5, Informative)

    by dnaumov ( 453672 ) on Monday April 07, 2003 @09:31AM (#5678330)
    This isn't exactly a recent change, I believe this happened over 6 months ago...
  • 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!
  • Spotted this on the list: U.S. Military helps fund Calgary Hacker [globetechnology.com]

  • Performance hit? (Score:3, Interesting)

    by mnmn ( 145599 ) on Monday April 07, 2003 @09:47AM (#5678426) Homepage

    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!

    • Re:Performance hit? (Score:4, Informative)

      by QuMa ( 19440 ) on Monday April 07, 2003 @10:39AM (#5678776)
      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)
      • The OpenBSD Apache chroot()s after its been run, so it loads all the libraries and modules as normal; no need for fancy mounts or copying libraries into the chroot.

      • Re:Performance hit? (Score:2, Informative)

        by Skapare ( 16644 )

        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

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

  • Why BSD? (Score:2, Insightful)

    by 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 Slashd

    • Re:Why BSD? (Score:2, Informative)

      by Nickus ( 10876 )

      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 [apache.org].

  • Does anyone have a bittorrent of the pdf? (Score:3, Insightful)

    by Idimmu Xul ( 204345 ) on Monday April 07, 2003 @10:09AM (#5678588) Homepage Journal
    Doing something like this in future as standard could conciderably reduce the /. effect!

  • Neat! I hope FreeBSD and NetBSD use this feature when they all merge [slashdot.org].

    Looking forward to it. ;)

  • Why don't the various Linux Dists... (Score:5, Interesting)

    by Greyfox ( 87712 ) on Monday April 07, 2003 @10:40AM (#5678780) Homepage Journal
    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.)
    • Same deal with propolice really..

      from what im told:
      gentoo comes with propolice, but its turned off by default "because some things break"

      in openbsd 3.3, propolice is turned on by default "because some things break"

      =D
    • Sounds like we need to create a distribution called 'OpenLinux' . . .
    • Well alot of the various linux distros really blow hard.

      The only one that dosnt, is gentoo. Its actually on a pretty level playingfield as freeBSD.

      Gentoo uses the ports collection, so you can get your chrooted packages off of there. But alot of times they dont run chrooted by default. This is changing at a good rate (in gentoo at least). When i do an overnight emerge, when i merge in etc-update i am finding that my chroot config directives are getting overwritten by the new config data more and more now.
    • Aside from all the very valid reasons everyone else has pointed out as to why various distributions do not chroot more services, there is one more: chroots, on many OSes (OpenBSD, Solaris, FreeBSD and default Linux kernels) are actually not that hard to escape from. With this in mind, some may consider chroots to have marginal value at best and at worst, they can create a false sense of security.

      For instance, there are several ways to get out of a chrooted environment that have been known for years. Fut

      • It sounds like the mknod problem could be solved with something like devfs. If devices always live in /dev/ and new device nodes cannot be created from userspace, then a chrooted environment really does restrict what devices you can access.

        I'm not familar with raw I/O - does this need a device file to open() first or do you specify the major and minor device numbers as part of the system call in some evil way?
    • I've always wondered why the various linux dists don't contain -chroot packages of the various servers that support the chroot environment.

      Mandrake have begun to.

  • Mirror (Score:2, Informative)

    by SonCorn ( 301537 )
    mirror [umr.edu]

  • Mirror (Score:3, Informative)

    by rf0 ( 159958 ) <rghf@fsck.me.uk> on Monday April 07, 2003 @11:17AM (#5679038) Homepage
    I've put up a mirror here [65535.net]

    Rus

  • Why is there an "Apache" user? (Score:4, Interesting)

    by mcrbids ( 148650 ) on Monday April 07, 2003 @12:17PM (#5679503) Journal
    The basic problem isn't that Apache runs as "userX" or "userY" or even "root", it's that it ONLY runs as user "apache"!

    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 ... logging, etc.
    </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.

    • Yes, it would be very nice but very difficult to implement given Apache's model and how that runs under Unix.

      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!

      The alternative is to run wi

      • Re:Why is there an "Apache" user? (Score:4, Informative)

        by cras ( 91254 ) on Monday April 07, 2003 @02:09PM (#5680168) Homepage
        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 [nimh.org] which could do that.

        • I see a number of comments in this thread.

          Anybody who says "it can't be done" is simply wrong. It can obviously be done, in a number of ways, with minimal repurcussions.

          I'd almost give a left nut for something like this that actually worked.

          So why hasn't it been done?
          • So why hasn't it been done?

            Want to pay for it? ;) I've thought a few times that this would be interesting to do, but I already have other projects and I don't actually need it.


          • Bind Apache to (say) port 8765 and NAT the incoming connections from port 80 to there.

            And for an encore?

            Change your user skeleton so public_html becomes a link to /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 gro

    • I've always set up Apache so CGI runs as the user who owns the site. The problem is, that requires retaining the permission to switch to that user somewhere, even if just within the "suexec" file (is suid root).

      The problem with Apache is that it is so large, and so much code would run as root, that it is unsafe to allow that. So the usual course is to run Apache non-root, and let "suexec" do the permission switch. Supposedly it can verify if it is being run correctly from the Apache process (as opposed

      • Maybe users should have to each run their own instance of Apache on separate IP addresses (they have to if they want to run an HTTPS secured web site, anyway).

        Of course, this negates the whole point of IPv4 address conservation that name-based virtual hosts afford.

        What if you could do name-based virtual hosting with each user running their own instance of Apache (using a single IP for Port 80 virtual hosts (machine-wide), which is probably most of what is on the server anyhow)? Port 443 virtual hosts w

        • Sure, it is doable to have a single IP working HTTP requests by name and have each site or group of sites (same user) have a dedicated server. I don't know how easy it could be retrofitted into Apache, but certainly one way to do this is to have a front end like a proxy that checks the host of the request and routes the request accordingly. Maybe that could be routed to a different port number according to a configured map. But I would be more inclined to route the requests to a named pipe in the filesys

  • It's nice but.... (Score:2, Insightful)

    by Lagos ( 67371 )
    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 env
    • Symlinks can't break out of chroot

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

  • Nice for some (Score:2, Interesting)

    by the-dude-man ( 629634 )
    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

  • Emergency Closing (Score:1, Funny)

    by Anonymous Coward
    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 stud

Slashdot Top Deals

Lots of folks confuse bad management with destiny. -- Frank Hubbard

Close