Slashdot Mirror

← Back to Stories (view on slashdot.org)

When Not to Use chroot

Posted by CowboyNeal on from the trust-no-one dept.

Hyena writes "Linux guru Alan Cox is quoted as saying 'chroot is not and never has been a security tool' in a KernelTrap article summarizing a lengthy thread on the Linux Kernel mailing list. The discussion began with a patch attempting to 'fix a security hole' in the Unix chroot command, trying to improve the ability of chroot to contain a process. When it was pointed out that people have been using chroot as a security tool for years, another kernel hacker retorted, 'incompetent people implementing security solutions are a real problem.' A quick search on the terms 'chroot+security' quickly reveals that many people have long thought (wrongly) that chroot's purpose was for improving security."

9 of 407 comments (clear)

  1. Or is it? by phorm · · Score: 4, Interesting

    The problem is that - for many root-running processes - running chroot has often been recommended as a security practice. This has often been the recommendation of the daemon authors, in the documentation, as a way to improve security.

    I think that this was once (or may currently be) the case with bind and various MTA's. Standard practice for many daemons now is to start as root and fork as another non-privileged user, but not every daemon has this option.

    1. Re:Or is it? by Niten · · Score: 2, Interesting

      I think that this was once (or may currently be) the case with bind and various MTA's. Standard practice for many daemons now is to start as root and fork as another non-privileged user, but not every daemon has this option.

      Any good sysadmin knows not to rely on a chroot jail to contain a process running as root. And if your MTA has to run as root, then it's a problem with the design of the MTA, not with the chroot mechanism. (If your MTA insists on running with root privileges, I highly recommend switching to Postfix if possible.)

      Chroot is an excellent tool. But as with all security devices, it's up to the administrator to know precisely what it can and cannot do, rather than relying on it blindly. That's sort of what sysadmins are paid for.

    2. Re:Or is it? by kestasjk · · Score: 2, Interesting

      I'm one of the people who, up until now, thought that chroot was for security (Luckily I've never had to rely on it though).
      In OpenBSD chroot is used to sandbox the web server, and as someone else pointed out the documentation often encourages people to chroot daemons. Also similar software like Solaris containers and FreeBSD jails, which do pretty much the same thing as chroot, actually are for security (pretty much exclusively in the case of jails, not exclusively in the case of containers).

      Also you'll often find chroot even on distros where there are no development tools to be found, which also encourages people to think that it's use goes beyond development.

      I think a nice big bold sign in man chroot is required, as well as removing all the advice that's currently around to chroot processes, if chroot isn't actually for security.

      --
      // MD_Update(&m,buf,j);
  2. Not for security use? by kcbrown · · Score: 3, Interesting

    A quick search on the terms 'chroot+security' quickly reveals that many people have long thought (wrongly) that chroot's purpose was for improving security.

    Not for improving security, huh?

    OK, genius, then explain why chroot() requires root privileges (or chroot capability) to execute.

    It's only in the context of security that such a restriction makes any sense at all.

    --
    Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
    1. Re:Not for security use? by QuantumG · · Score: 2, Interesting

      Hard link /usr/bin/su to ~/usr/bin/su. (Yes, you can create hard links to files which you don't own.) Yes, and there's the bug.. which hasn't been fixed for 40 years.

      try for yourself:

      $ id
      uid=1000(you) gid=1000(you)
      $ cd /tmp
      $ ls -l /bin/bash
      -rwxr-xr-x 1 root root 700560 2007-04-11 09:32 /bin/bash
      $ ln /bin/bash foo
      $ ls -l foo
      -rwxr-xr-x 2 root root 700560 2007-04-11 09:32 foo

      Uhhh, why is a regular user allowed to create a file owned by root?

      $ rm -f /bin/bash
      rm: cannot remove `/bin/bash': Permission denied
      $ rm -f foo
      rm: cannot remove `foo': Operation not permitted

      Awesome, the semantics of directory permissions are not even honored anymore.. anyone else smell a kludge here?

      --
      How we know is more important than what we know.
  3. Re:misleading... by risk+one · · Score: 2, Interesting

    So is the point of chroot safety rather than security? Ie. used to circumvent the "don't do stuff as root, because mistakes can have bad consequences" thing? I'm not intimately familiar with chroot, but this is how I understand it. It's possible to break out of a chroot jail (therefore don't use it for security), but it's unlikely that you'll do so accidentally (therefore feel free to use it for safety).

    Is that about right?

  4. Re:Then what is it for? by soloport · · Score: 5, Interesting
    What's it for?

    https://portal.mytesting.org:8080/ (including)
    * tinyHTTP (AppWeb, Apache, etc.)
    * SQLite (MySQL, Postgres, etc.)
    * [chroot-path-0]/www/html/*
    * Other ([chroot-path-0]/usr/lib, [chroot-path-0]/bin, etc.)
    and repeat...

    https://my-test-env.org:8081/

    https://my-test-env.org:8082/

    https://my-test-env.org:8083/

    https://my-test-env.org:8084/ Next, bind /proc to all 5. Then make a script to easily update them from SVN. Done.

    Now you have 5 chroot'ed web environments to help your test team (of 5) speed up Alpha testing. May be fraught with bad security? That's not the point.
  5. Overtaken by virualization by flyingfsck · · Score: 3, Interesting

    Basically chroot was an early attempt at virtualization. It allowed one to keep servers separated and contained, which improved reliability and availability. It has a minor positive effect on security, but not really all that much. There is a good argument to be made for not using chroot since it increases the maintenance effort, which frequently results in chrooted servers being neglected which reduces security. As for myself, I avoid using it, due to the maintenance issues.

    --
    Excuse me, but please get off my Pennisetum Clandestinum, eh!
  6. Re:Excellent explanation by SL+Baur · · Score: 2, Interesting

    It doesn't make sense. Using chroot(2) for security is like trying to fit a round peg into a square hole that it was never intended to go into.

    It also doesn't make sense that certain inbound TCP ports are restricted to being bound only by root, but that's the reality we have to live with.

    <Thought-experiment>
    Wrap your mind around the fact that it is Microsoft Windows userland now that causes most of its insecurity. If you could cleanly separate Microsoft Windows userland and run it under an Open BSD kernel, it would still be insecure. Conversely, if you could run an Open BSD userland under a Microsoft Windows kernel, it most likely would be more secure (sans Microsoft programming and design errors).
    </Thought-experiment>

    Chroot will not and cannot defend against the ill-advised practice of running binaries ("trusted" or not) received off host. Yes, I'm also looking at you Mac OS X, which is otherwise a lovely system.