OpenBSD Journal

Using OpenBSD's chrooted apache

Contributed by jose on from the as-seen-on-Slashdot dept.

BSDForums.org writes to Slashdot and to us:
"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."
Very cool, Marc, glad to see someone is showing others how to make use of this feature while still serving up complex content. Thanks!

(Comments are closed)

Comments

  1. By Anonymous Coward () on

    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. Comments?

    Comments

    1. By Anonymous Coward () on

      How can you use such code to brake out of chroot on OpenBSD?

      Grsecurity enforces some extra (non standard) stuff. Why is this needed? That's not what chroot should be used for!

      Comments

      1. By Dries Schellekens () on

        Yes, if you want to enforce extra restrictions (disable certain system calls) inside a chroot, you should use systrace. This should not be part of the chroot implementation.

    2. By Anonymous Coward () on

      They test from root user, and that's it (why would you deny him to rise priority of some process???)

    3. By Fábio Olivé Leite () foleite@yahoo.com.br on mailto:foleite@yahoo.com.br

      It seems they don't really know what they are testing. If you take a look at their chroot_chroot_test.c you'll see that they basically test if you can call chroot twice, which means nothing.
      Once you chroot, your / becomes what you chrooted to, since that's what's supposed to happen. They seem to think that if you call chroot("/") inside the new root you'll go back to the system's root, which is just plain wrong.
      They should at least check with stat that the device and inode for / go back to the original ones or something.

      Maybe they just like the ego boost of seeing all those PASSED for their system and FAILED for the others, by testing non-bugs and "fixing" them.

      Comments

      1. By Anonymous Coward () on

        Chrooting inside the chroot can be used to break out via traversal and other methods. Perhaps you weren't aware of this?

        Either way, their testing isn't worth much.

        Comments

        1. By Fábio Olivé Leite () foleite@yahoo.com.br on mailto:foleite@yahoo.com.br

          > Perhaps you weren't aware of this?

          No, I wasn't. Do you have any URLs? Anyway, I guess those are attacks against a buggy chroot implementation, not the chroot concept.

          Comments

          1. By tedu () on

            man 2 chroot, WARNINGS section. short version: if someone gets root in chroot, it's all over.

            Comments

            1. By Fábio Olivé Leite () foleite@yahoo.com.br on mailto:foleite@yahoo.com.br

              > short version: if someone gets root in chroot, it's all over.

              And what does that has to do with being able to chroot twice? Sounds like fixing the wrong bug. "Someone" was not supposed to get root in the chroot to begin with.

              If user foo wants to slowly chroot into /home/foo/very/long/path/to/chroot/environment one subdir at a time, fine. He will only get more and more restricted as he goes deeper. But if he can suddenly find a root exploit in there it's a completely different problem.

              Comments

              1. By nother () on

                the main point of their report is that it is a bit flawed - they consider a plus some extra restrictions unrelated to changing root of application's filesystem...
                most of their tests want uid(0) anyway to execute test-exploit-whatever

      2. By boredom () on

        Not to say that Grsecurity doesn't know what they're doing - but they definite have a beef with OpenBSD (and others). Their April Fools "joke" was little more than an outright attack of various other projects, and OpenBSD figured pretty prominently (others mentioned: OWL/Solar Designer, Trustix/Crispin, Dave Wheeler, et al).

        They have quite a bit of animosity towards others, which just seems lame in the world of open source. I can understand the religious wars, and the battles over license choices. In their case, they just seem bitter because other people get more credit than they do, and borrow ideas from them, without using their specific implementation.

        I guess that would be fine in the commercial world, but just seems wrong when you're already trying to support other 'communal' systems.

        Comments

        1. By Anonymous Coward () on

          i must say that your post is quite typical of what can trigger the April Fool's joke you had a
          beef with ;-). so, in order of mentioning:

          1. beef with OpenBSD: if there's anything like that then it's probably because of the apparent
          discrepancy between what OpenBSD actually provides (we're talking about 'security' here) and what
          people at large think it does. the chroot stuff (some of which works as non-root as well, mind you)
          is just one of the many, whether you (the public at large) know about it or not. since this difference
          is positive (public assumes more than reality), there must be some propaganda going around here,
          don't you think?

          2. beef with others: nothing with Solar Designer, in case you missed the joke, it was referring
          to people who mistook PaX with his non-exec stack patch over the years. Dr. Cowan is associated
          with Immunix, not Trustix (last i checked at least) and they're well known in the industry for
          delivering (or not) on time ;-). if and when you read Dr. Wheeler's HOWTO, i'd like to know what
          you think about it (the parts mentioned), in particular the unmistakable (and not justified) bias
          towards StackGuard and downplaying others.

          3. animosity towards others: any evidence for this?

          4. bitterness about (lack of) credits: really, do you think it matters? i mean, if we had
          cared about it, couldn't we have spread our own propaganda all these years? there're enough forums
          for computer security after all (both on-line and off-line), it wouldn't have been hard to spam
          them. but it didn't happen, and the reason for that is very simple: our software spreads by word of
          mouth (i.e., based on its own merits), not propaganda (i.e., not based on perceived merits).

          5. as for the "bitter because [...] borrow ideas from them, without using their specific
          implementation": any evidence for this? also, how about (the lack of) crediting the ideas
          themselves in the first place? you put it well when you said: it "just seems lame in the world of
          open source".

          6. finally, cheer up please, April Fool's got its name for a reason, only the fool gets fooled... ;-)

    4. By Anonymous Coward () on

      BS.

    5. By awk fu () on

      how about patches so it will compile on Free^H^H^H^HOpenBSD?

    6. By tedu () on

      the following might be interesting reading for some of you. behold the power of google!

      http://www.bpfh.net/simes/computing/chroot-break.html

  2. By Bebop () on

    Does OB have jail like FB does?

    Comments

    1. By Anonymous Coward () on

      NO.

      It still has a while to go before it is a secure os.

      --billy

      Comments

      1. By Henr () on

        OpenBSD does not even have jail?...geeeeeee....

    2. By nother () on

      what's the difference - mighty grsecurity tests only chroot()

  3. By Anonymous Coward () on

    ptrace, shared memory, semaphores, message queues, abstract unix domain sockets: These work regardless of the security of the application inside the chroot. If the application is written poorly, you also have fchdir, not to mention the many more depending on the root privileges that exist within the chroot.

    It's not just double-chroots anymore (as some would believe).

    The regression "tests" are merely "tests", not exploits. They test enough to prove that a particular exploit could be launched on the given OS. (And the exploits do exist)

    You might want to check your facts for once instead of repeating your "OpenBSD is secure" mantra.

    Comments

    1. By Anonymous Coward () on

      Is it possible to break out chroot as an unprivilegded user? Doesn't this require a local kernel exploit?

      Most OpenBSD daemons chroot to /var/empty and drop priviligdes.

      Comments

      1. By Anonymous Coward () on

        It doesn't require any kernel exploit. It can be done regardless of what's in the chroot. OpenBSD leads you into thinking if you're in a chroot with nothing in it as non-root, there's nothing that can be done, and that is completely false.

      2. By tedu () on

        his definition of "break out of" is retarded. he doesn't know what chroot is supposed to do. yes you can "break out of" a chroot by sending a signal to another process. that's the way it works. the way it's supposed to work.

    2. By Dries Schellekens () on

      ptrace, shared memory, semaphores, message queues, abstract unix domain sockets: These work regardless of the security of the application inside the chroot.

      If you don't want these system calls inside the chroot, use systrace to disable them.

      GR Security has these restrictions by default, so what! OpenBSD can too.

      Comments

      1. By Anonymous Coward () on

        whatever happened to "secure by default"? Sounds like a case of shoulda-coulda-woulda. You really think systrace users know all the system calls that can be used to break chroot, and know how to restrict them appropriately? The developers don't even know: exhibited by the blatant holes in all the publicly available systrace policies.

        Comments

        1. By Anonymous Coward () on

          Given time, documentation and understanding of systrace policies will be more prevelant. It is my understanding (which at this time of the morning after a night like last night is probably pretty bad :P) OpenBSD does not include stricter default systrace policies because they would not make the software usable by a large amount of people. Someone who is new to OpenBSD and systrace may see a "problem" that is caused by a strict default systrace policy. That "problem" would most likely cause more traffic on the mailing lists asking questions about the default setup or flaming because something is not "working."

          Now, if we all stopped sitting around with our balls in our hands saying "my software is the best for everyone and everything!" and spent that time making better software, writing better documentation, and presenting things better (I saw no "about" page on the grsecurity site, so finding quick information as to what it actually did was a little more difficult) we could all have better software and a better understanding of how that software works.

          Oh well, this is getting long and I am getting into that "Why can't we just get along!" sort of mood. So have a great day, and I look forward to looking for more information on these subjects and possibly trying the software you have written.

          Comments

          1. By Anonymous Coward () on

            If you had looked for more than 3 seconds at the page and understood english, you would know that the "features" (good name for it, huh?) contains several pages of feature listings.

            Comments

            1. By Anonymous Coward () on

              You're probably right. The features section does cover that well. I am not sure why I did not see it yesterday. I take that part back, sorry! :)

            2. By Fábio Olivé Leite () foleite@yahoo.com.br on mailto:foleite@yahoo.com.br

              > If you had looked for more than 3 seconds at the page and understood english ...

              Now _that's_ some prejudice, heh? Are you from USA? I mean, that would explain the arrogance.

              I've just noticed in your site that grsecurity is a security patchset for Linux. That may also explain your attitude against OpenBSD.

              BTW, while I was browsing your site with Konqueror and tried to view the slides of that second paper in the list, the page complained that it was optimized for a newer version of Internet Explorer... weird!

          2. By Anonymous Coward () on

            BTW your argument is the exact antithesis to the goal of OpenBSD. They claim to put security ahead of user-friendliness. Examples: having nearly everything disabled by default to the point of making the box useless, putting apache into a chroot by default and breaking CGI, etc. So why should this be any different, unless OpenBSD fails to see the problem, or just doesn't care? (in either case, they SHOULD care, because it IS a problem, and IS being exploited).

            Comments

            1. By Anonymous Coward () on

              Good documentation is not against the goals of OpenBSD. In fact, I think they have some of the best documentation for free software out there. Not all of the documentation for OpenBSD, systrace, PF, etc is written by OpenBSD developers. This is a community of users after all.

              Theo has mentioned in atleast one email to misc@ and probably other places that they do not disable everything because a system that has everything disabled *is* useless. They want a secure but usable system.

              There have been times they have something working one way, do not see a change as worthwhile, and then change later down the road when they have the time and motivation to work on it or something comes out to change their minds. Maybe if someone shoved enough proof in front of them they could or would fix whichever bugs are being exploited.

    3. By Fábio Olivé Leite () foleite@yahoo.com.br on mailto:foleite@yahoo.com.br

      > ptrace, shared memory, semaphores, ...

      Can you provide an example of how one would go about breaking out of a chroot by using a semaphore or shared memory? This really sounds like some random rant without facts, so please provide some evidence, I'm really curious here.

      > ... depending on the root privileges that exist within the chroot.

      Which should be none. :)

      Comments

      1. By Anonymous Coward () on

        You asked for it...so here it is:

        Shared memory can be used to break out of a chroot as non-root. It's common for non-root apps to be run as the same uid (usually "nobody"). You need to target some shared memory in use outside the chroot by the same user. Apache is a good target on systems where apache isn't chrooted, but other apps are. Simply shmget the shared memory (the key can be pre-determined or bruteforced). The shared memory can be marked as private, it doesn't matter to the exploit. All that is left is to shmat() the shared memory shmget() returned the id of, and write to it. Since you're dealing with raw memory, there is no way the application using the shared memory can't be exploited, since even if it were to do bounds checking every time it accessed anything from the shared memory (which is never done) there are race conditions involved. So, overflow an integer, lengthen a character array...you control the process outside of chroot. And thanks to OpenBSD's incomplete and ineffective non-executable protections (remember, on i386 it's still only a non-exec stack) you can execute code in the shared memory. Game over.


        Was that a random rant without facts?

        Comments

        1. By Anonymous Coward () on

          > It's common for non-root apps to be run as the same uid (usually "nobody").
          I tought OpenBSD ran every service as another uid?

        2. By Fábio Olivé Leite () foleite@yahoo.com.br on mailto:foleite@yahoo.com.br

          > It's common for non-root apps to be run as the same uid (usually "nobody").

          OK, so considering that OpenBSD runs every daemon as its own uid, this point is bogus.

          And I doubt OpenBSD could be blamed for every poorly coded daemon the user chooses to run which does not ensure proper checking of its shared resources, like memory segments. Can you exploit such a situation in an OpenBSD full install (no ports, obviously)?

          Comments

          1. By Anonymous Coward () on

            > OK, so considering that OpenBSD runs every daemon as its own uid, this point is bogus.

            Ok, fine, let's assume no one adds any 3rd party software to their OpenBSD box, and leaves it as the useless default install with only OpenSSH running. OpenSSH's empty non-root chroot can still be broken. How you ask? Because of exactly the thing you talk about...."OpenBSD runs every daemon as its own uid." This is very true. Their "privilege separation" pipes all connections to ssh through a single non-root user. Hack your own connection, you own that user. ptrace the other processes, you can grab everyone else's passwords, including root. How's that, sir? You can continue to blindly defend OpenBSD, but the facts are out there for people who want to know the truth.

            Comments

            1. By Anonymous Coward () on

              I would like to contact you fine sir, I have some things I would like to discuss with you. Is there perhaps a point of contact available?

              Maybe make a temporary hotmail account where I may contact you?

              I suppose this is not possible, as I will have no way to ensure you will be the person who will reply.

              Comments

              1. By grey () on

                Not to get too off topic, especially seeing where this thread has been going, but I thought I'd lend a voice for a bit.

                This sounds like the same fellow of most grsecurity posts. Just check their forums for a bit and you can reason who it might be judged from writing style.

                My guess is this is spender/Brad Spengler since he seems to be the moderator for all the forums there, his addy is spender@grsecurity.net. Alternatively, you could try writing dev@grsecurity.net and see what happens, since that's listed there.

                It's hard to say without a name attached, he might not have any official affiliation with the project. I don't with OpenBSD, but debating things doesn't require that after all.

                Anyway, I must say that Fábio Olivé Leite has been doing quite a job in attempting to ellicit more detail from someone who seems happy to throws his hands up in the air in exasperation without affording extensive details. I appreciate that, since efforts like Fabio's can raise the bar of everyone's awareness, even when the person pointing faults isn't giving complete information.

                This all does seem a little odd, since I never interpretted chroot as being much of a security feature. Looking at the GRSecurity modifications to chroot - it definitely looks neat, but what it has in relation to a traditional Unix(tm) chroot is beyond me. Other folks who have done extensive jailing have chosen different names in the end like jail, or TPE.

                I do see some validity to pointing out wariness to a false sense of security that some might have with OpenBSD. I just don't agree with the assumption that OpenBSD developers and users actually believe that they're really guaranteed security.

                I've never seen an OpenBSD developer (or at least not Theo) ever claim that OpenBSD was the most secure OS. Security is certainly a goal, and a pretty loftily held one, but the way they go about it has historically been through bug fixing and insuring -correctness- rather than implementing countermeasures.

                Just look at propolice, Theo has long had arguments against technologies such as the recently incorporated propolice precisely because they don't fix the root cause of security problems, of bugs and poor design, and can lead to a false sense of security. I'm glad that he's finally seen merit to other things for defense in depth, but from what I've seen the primary goal in OpenBSD security efforts has been to correct flaws in code e.g. the new strl* change efforts, will hopefully clean up remaining string problems, assuming strl* is used properly, which is probably pretty likely.

                GRSecurity obviously has its own goals, but I don't see how they need to be clashing with OpenBSD right now. The 'secure by default' refers primarily to a mindset of default configurations in a complete and functional Unix environment, it is not the be-all-end-all of security, and I don't think that OpenBSD developers or users make such claims. That statement merely reflects a baseline attitude, really, it's that trivial. No one has ever said that once you install OpenBSD your concerns are over, but rather that you're off to a good start.

                Since GRSecurity appears to have some pretty nifty features and is multi architectural, I would even see room to encourage a port to a different platform like OpenBSD where the mindset of the users would welcome it. However, due to licensing issues, I doubt that would ever be incorporated into the base install. It wouldn't be the first or last set of utilities designed to bring further security to OpenBSD.

                The one thing that really bugs me about this poster is that he assumes that OpenBSD users and presumably developers are living life with their blinders on, simply consuming propoganda. At least speaking personally, I feel that's completely untrue. And while users and developers may take pride in the way OpenBSD goes about doing things, I don't think any of them blindly make or accept claims - be they true or false. Announcements of new features or revelations of unfound bugs are not a claim that there isn't more work to be done.

                If there weren't more work to be done, then life would get pretty uninteresting pretty quickly.

                I really hope to see operating systems even more secure, and even more user friendly in the future. I don't know if OpenBSD will provide all that, but for the time being I feel that their approach (and they're not the only ones, but they're the focus of this discussion at least) is the closest to how things should progress onwards in my opinion.

                If someone else came out with an OS tomorrow that was super secure, liberally licensed (BSD, MIT or maybe public domain), free and extremely functional - I don't think I would be the only OpenBSD user (or even developer) to check it out.

                Until that happens, from an operating system level (not just a set of patches) - OpenBSD is not perfect by a long shot, but it's pretty darn good.

                Comments

                1. By Joel Rees () joel@alpsgiken.gr.jp on http://www.alpsgiken.co.jp

                  ---------------quote------------------------
                  The one thing that really bugs me about this poster is that he assumes that OpenBSD users and presumably
                  developers are living life with their blinders on, simply consuming propoganda.
                  --------------------------------------------

                  It strikes me that the assertion that the listener has blinders on is typical of someone selling new and improved blinders.

            2. By Fábio Olivé Leite () foleite@yahoo.com.br on mailto:foleite@yahoo.com.br

              > ... ptrace the other processes, you can grab everyone else's passwords ...

              Hey! You seem to have a point here. Reading ptrace(2) I found that PT_ATTACH allow a process to trace any other processes running under the same real uid. In Linux, for example, there's the added constraint that the traced process be a child of the tracer. Perhaps OpenBSD should embrace that constraint.

              Congrats! We managed to prove one of your points with facts instead of macho talking! :)

              > You can continue to blindly defend OpenBSD, but the facts are out there for people who want to know the truth.

              Right on, Fax Mulder. Now where's Dana SCSI to support your quest.

              Serious, though: see, you could have made your points clearer from the start by explaining your points, instead of just telling people how big your dick is or something.

              If the OpenBSD crowd sings the mantra of secure by default or whatever, it's because of a history of bug-fixing and code audit. Of course anyone can cvs checkout and quickly fix a bug that has not yet been given enough attention by the OpenBSD developers, so that they can have their own "even more secure" OS for some time.

              But how long will you be playing that game? Have you considered that the other projects might appreciate your help, since you are so enlightened? Or have your ego been too much in the way for you to understand that it's all about "sharing" instead of "comparing and bitching about it"?

              Comments

              1. By Anonymous Coward () on

                I don't want to talk more about this subject. But please look at it this way. In any other industry, would you say "here's our secet sauce to put on burgers. If you use this sauce, your burgers will taste much better." I don't think you would. Though we are talking about open-source, you should not expect everyone to act like socialists and contribute to competing projects. Healthy competition helps everyone, just as it works in the commercial world.

              2. By Anonymous Coward () on

                BTW I should point out an inaccuracy in your statement. PT_ATTACH can be used in Linux, the same as it is used in OpenBSD, FreeBSD, etc.

                Comments

                1. By Fábio Olivé Leite () foleite@yahoo.com.br on mailto:foleite@yahoo.com.br

                  Indeed, I mixed it up with the constraints imposed on access to a process' VM via /proc/pid/mem. A few years ago I needed to do that in Linux and found out that you have to be the father of the pid whose VM you're trying to access and the pid should be traced. Sorry about that.

                  I agree to end this thread here. I just want to add that you might not want to count me in the "stubborn openbsd crowd" since I've been using Linux for more than 8 years now, and just a few months ago got really interested in OpenBSD.

                  I do value a good technical discussion based on facts, though, and that's why I defended OpenBSD: to get you to provide some facts. :)

                  Regards

              3. By tedu () on

                if you don't want people to ptrace:
                vi sys/conf/GENERIC
                /PTRACE
                dd
                :wq

                config make cp reboot

                ignoring the fact that chroot has NOTHING to do with ptrace or signals or shared memory or ...

                Comments

                1. By Anonymous Coward () on

                  what you don't seem to understand is that the problems are not with chroot() per se, but what people are using it for under the false assumption of 'increased security'. you can't have it both ways, chroot() either increases security and OpenBSD (and others) rightly use it for everything or it does not and then you have no rights to mislead people. given what was already presented or hinted at it should be clear that chroot() is USELESS for 'increased security' because it can be broken without taking additional measures. that's the lesson you should have learned had you not dug yourself into that hole of self-confidence.

                  Comments

                  1. By Fábio Olivé Leite () foleite@yahoo.com.br on mailto:foleite@yahoo.com.br

                    Ugh, couldn't resist so here I am contradicting myself and continuing this thread.

                    What _YOU_ don't seem to understand is that no one in the Unix history ever said that calling chroot(2) puts your process in an isolated virtual machine. You could use user-mode-linux for that, since you are Linux oriented (and yes I know what I'm talking about).

                    chroot(2) does what it's intended to do: change the FILESYSTEM root of the calling process to a point deeper in the FILESYSTEM tree so that it will not be able to access FILES in the other branches of that tree.

                    Anything else is a bug in some other place, so complain about that other place, not chroot.

                    Comments

                    1. By Anonymous Coward () on

                      chill down and don't put words into my mouth i never said. then also take a look at the beginning of this thread. it says: Using OpenBSD's chrooted apache. now let's think together a bit. why do we need apache in a chroot? no need to guess actually, the author himself tells us in no unclear words:

                      -----------------------
                      OpenBSD recently changed the mode of operation for the Apache web-server 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.
                      -----------------------

                      see, at least he believes it enhances security. so who are you really arguing with? and what about sshd in chroot decided by no less authority than core OpenBSD developers? are you saying they didn't understand what (little) chroot() achieved? if there's anyone who you need to educate then it's all the people who're using OpenBSD's (and other's) chroot() for whatever 'increased security'. notice that i'm not arguing pro or contra for using chroot() per se, but i'm trying to make it clear that using it as it is for 'increased security' is just plain wrong. whether you want to solve that problem by fixing chroot() and related issues or develop a whole another solution or switch to another OS is none of my business.

                      Comments

                      1. By Fábio Olivé Leite () foleite@yahoo.com.br on mailto:foleite@yahoo.com.br

                        > chill down and don't put words into my mouth ...

                        OK, that was a bit over the top. Sorry.

                        > ... using it as it is for 'increased security' is just plain wrong.

                        Well, I still think it increases security, as it makes things more difficult for an attacker, by providing him with an environment with less resources. Of course it's not the holy grail of server security, but it helps. And that's what is meant by "increased security".

                        Perhaps we'll have to agree to disagree.

                      2. By djm () on

                        Of course it enhances security, it hides the majority of the filesystem from non-root users. It might not offer a total jail according your arbitrary definition, but it is an improvement of unpatched Apache.

                        Comments

                        1. By Anonymous Coward () on

                          but is *trivial* to break out of, so offers *no* protection.

                      3. By Henning () henning@openbsd.org on mailto:henning@openbsd.org

                        I am the author of the chroot extensions for apache in OpenBSD.

                        These are NOT my words.

                        chrooting apache increases security indeed. But not for it alone. I have done more than just chrooting. In fact, I see the privilege drop in the parent process as the most important change. The chroot() heavily helps in securing.

                        chroot() for it alone doesn't make much of a difference; chroot() as part of a bigger security enhancement like what we did for apache is very powerfull and does increase security.

                        Your constant babbleings about breaking out of the chroot() we impose in httpd are backed up by nothing, so shut up or come up wiith facts.

                        Comments

                        1. By Anonymous Coward () on

                          Harsh words. So unfortunate the OpenBSD developers are so clueless, yet have so large egos.

                        2. By Anonymous Coward () on

                          look at the first story, it has source that allows breaking out of chroot.

            3. By djm () on

              You don't get it. ptrace() won't work, as you _can't ptrace processes which have set[ug]id_ and OpenSSH doesn't use SysV shm.

              You can continue to ignorantly blab on about false exploits, but you have yet to demonstrate one.

              You rant and accuse others of not wanting facts, but when you actually respond with something factual, it is obvious that you don't know what you are talking about.

    4. By djm () on

      You say "broken out of", but you don't really qualify what that means. If you mean "can use the syscalls you mention", then duh - chroot isn't intended to stop the use of syscalls (other than mknod). If you mean "can escape and read areas above the new root", then you have not demonstrated this adequately.

      The "comparison" at http://www.grsecurity.net/compare.php misses the point in a fairly major way. All of your chroot tests only make sense if you don't give up root privileges inside the chroot - which is obviously wrong and is NOT what OpenBSD does.

      BTW your regress test has at least two bugs in it:

      http://cvsweb.grsecurity.net/index.cgi/regression/chroot_chdir_test.c?rev=1.1.1.1&content-type=text/x-cvsweb-markup

      You seem more interested in competing (or more accurately, "trash-talking") than improving the state of the art. You deliberately ignore systrace, securelevel and current practice so you can cheaply score a few points.

      Comments

      1. By Anonymous Coward () on

        I'm not ignoring anything. securelevel is ineffective at stopping many of the attacks. As for systrace, how can you protect against an attack you don't even understand? No one who has posted here knows how to break a chroot, how do you expect them to define a systrace policy that stops such attacks?

        You're more interested in shoulda-coulda-woulda than what the actual state of things are. The tests that can be launched as non-root don't need to be run as non-root to prove the point. If you understood what was going on, you would know that.

        Comments

        1. By Anonymous Coward () on

          Duh, you don't have a clue of how to define your systrace policy:
          • allow every which happens under normal behaviour and deny everything you don't need
          • start with denying everything, add rights till it works

        2. By Fábio Olivé Leite () foleite@yahoo.com.br on mailto:foleite@yahoo.com.br

          > No one who has posted here knows how to break a chroot ....

          Surely you ran a poll and had everybody in the audience to answer it, before jumping into that conclusion?

          > You're more interested in shoulda-coulda-woulda ...

          Hmmm I guess you are the one who is more interested in proving how macho you are with your questionable security concerns.

          Please start posting with your real name, it's getting difficult to understand who is answering to whom here (although I recognize your posts by your language and attitude).

          You see, I'm really curious about all the points you raised, but it gets difficult to discuss things when you underestimate everybody else so much. Perhaps you need to get laid or something so that you'll calm down a little.

          Comments

          1. By Anonymous Coward () on

            I give up. OpenBSD users are a unique brand of humans. I can deal with arrogant intelligent people, but arrogant OpenBSD users who have no clue what they're talking about are the most stubborn people on Earth. I guess it's too much to ask you to think reasonably instead of resorting to defensive arguments after your OpenBSD security bubble is burst.

            As for my statement about no one knowing how to break a chroot, it still stands. I have yet to see anyone post here with a shred of technical fact to refute my claims, only "but it's OpenBSD, the most secure OS in the world, it cannot be wrong!"

          2. By Anonymous Coward () on

            > Surely you ran a poll and had everybody in the
            > audience to answer it, before jumping into that
            > conclusion?

            do you realize that the very core of this question defeats the naysayers' point? ;-) see, if the OpenBSD chroot cannot be broken, then there cannot be people who know how to do it - the original statement stands. now on the other hand, if said chroot can be broken, then those in the know number 1 here (the original poster), so the rest still comes out at 0.

        3. By djm () on

          You ignored the first and most important part of the post, the bit where I asked you to define what you meant by "break out of a chroot".

          Breaking out as root doesn't count, using syscalls which have some effect (e.g. kill) outside the chroot doesn't count, breaking out of a chroot where you haven't done a chrdir("/") certainly doesn't count.

          You seem to be labouring under the misconception that chroot is general privilege lowering mechanism, it is not (except in the most restricted sense). You want gaol() or whatever it is called from FreeBSD. As I mentioned, the OpenBSD way of doing this is systrace.

          chroot exists to limit an unprivileged process' access to the filesystem, nothing more.

          I agree that systrace should be used to further restricte chrooted processes in the default install, but then you could do most of what your patch does on Linux with capabilities anyway. Why don't you contribute some policies? I suspect that you would prefer to anonymously whine and self-promote (you didn't help the MicroBSD guys out in a past life, did you?.

          Comments

          1. By not same guy () on

            the problem with your statements here and in another post is not about what chroot() does but (how many times shall we repeat it) the fact that it is NOT effective, it is an obscurity measure (and an OS putting security in front should not use such). you assume that your attacker who takes control of apache (or whatever) doesn't know how to break out of a non-root chroot hence you say it is an effective stop-gap measure. were the premise true, you would be even right. the whole point of the original poster is that your premise it WRONG. seriously, have you even TRIED to run those regression tests on your OpenBSD as non-root? if and when you actually do it and understand the results, let us know.

            since you brought up systrace: it has design deficiencies, which were brought to the attention of its author long time ago, but you see, he knows better. example: what's the goal of restricting execve() based on its arguments when you don't (read: CANNOT, in the current design) do the same for mmap()? take a look at the sample apache policies at http://www.citi.umich.edu/u/provos/systrace/usr_sbin_httpd . it says among others:

            native-fswrite: filename match "/logs/*" then permit
            native-mmap: permit
            native-mprotect: permit

            do you realize that that's all one needs to execute arbitrary code (even despite non-exec pages, etc)? this is a design issue and there's no fixing it with any (useful) policies. see, if systrace were worth its salt, knowledgable people would be using and contributing to it. that's all for now, awaiting your response (hopefully you get down from your pedestal and say some technically sound arguments finally).

            Comments

            1. By Anonymous Coward () on

              If chroot is broken after apache has been compromised, this does not mean chroot is ineffective.

              chroot is still effective b/c it prevents different attacks, like poorly written cgi/php/ssi that opens and displays files based on user input from reading anything in /etc or other dirs.

              chroot is like a bullet proof vest - it will protect you in a specific place from a specific attack. Give a cop the vest, do you really think he will complain "this is ineffective, i am still vulnerable to grenades, rpg's, chemical warfare and more! What if they shoot me in the face or legs??"

      2. By Anonymous Coward () on

        Agreed - especially when they disable ramdom pid on latest solaris

    5. By tedu () on

      you should read the man page for chroot sometime. it is a file system NAMESPACE altering function. it does NOT change the priveleges, rights, or permissions of the process. it changes the root directory for a process. that's it.

      get over yourself.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]