Slashdot Mirror


Chroot Jails Made Easy

GonzoJohn writes "There are always difficult jobs to do as a GNU/Linux system administrator. Sometimes the difficulty lies in finding out how to do a particular job, not necessarily the job itself. This can be particularly true in the open source world where documentation can often take a back seat to implementation. But once in a while, you can stumble on a real gem that simplifies even the most difficult administration tasks. One such gem is the Jail Chroot Project. Linux Orbit introduces you to creating chroot-ed environments in this article."

10 of 87 comments (clear)

  1. what do I do with it? by jericho4.0 · · Score: 4, Interesting
    The chroot jail approach is pretty cool, and gives a great layer of security for the system too.

    In the long run, though, I hope the standard aproach becomes User Mode Linux.

    --
    "A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
  2. Feature Request: RPM Integration by mbogosian · · Score: 4, Interesting
    The chroot jail looks like a tinkerer's paradise. My only question is how is software installation done for non trivial programs?

    From the site:
    Now, we are going to install the 'awk' program into the chrooted environment. We need to call the addjailsw script with the -P argument:
    /usr/local/bin/addjailsw /var/chroot -P awk
    The output for the script will be something like this:
    addjailsw
    A component of Jail
    http://www.gsyc.inf.uc3m.es/~assman/jail/
    J uan M. Casillas

    Guessing awk args(0)
    creating /var/chroot//lib/libc.so.6
    Warning: file /var/chroot/lib/libc.so.6 exists. \
    Overwritting it
    creating /var/chroot//usr/bin/awk
    creating /var/chroot//etc/ld.so.cache
    Warning: file /var/chroot/etc/ld.so.cache exists. \
    Overwritting it
    creating /var/chroot//lib/libm.so.6
    creating /var/chroot//lib/ld-linux.so.2
    Warning: file /var/chroot/lib/ld-linux.so.2 exists. \
    Overwritting it

    Done.
    Again, not to minimize the outstanding work here, but what if I want to create chroot jails for the LAMP class I'm teaching (I'm not really, but this seems like a cool application) so they can all have their own Apache installations? It sounds like chroot will know to move the httpd binary and the required shared libraries, but what about the rest of the admin shell scripts, server root, shared icons dir, mime types file, etc.?

    Then what happens if I want to upgrade? My guess is a fair amount of bootstrapping needs to be done in the new root....

    What might be really cool is for addjailsw to be RPM-aware so I could do a addjailsw mod_ssl-2.8.7-6 which would get a list of necessary files and package dependencies and install them in the new root and update the RPM DB in the new root as well.

    Maybe just wishful thinking....
    1. Re:Feature Request: RPM Integration by Doc+Assman · · Score: 4, Interesting

      Hello

      Yes. This can be the right approach to this. If you have all the packages ready for install into jail, you can jail a whole system :) But when you change the original package, you need to re-package the 'jail' version.

      But, lets go one step far: what about to create a script that generates the jail package ? this shouln't be so difficult: jail explores the binary files (and a dry run) in order to extract the 'dependencies' of this file. But you can explicity say what are the dependencies (e.g. you can tell the packager that apache requires the bin/* files, the conf/* files, and the libexec/*, plus all the required libraries (found when jail explores all the binary and library files)

      I think on this, it looks useful!. For now, what wants to create a .deb or .rpm packages for jail so it can be included in some distros

  3. Apache in Jail by Anonymous Coward · · Score: 1, Interesting

    This book will teach how to jail apache.

  4. chmod jail? by Lord+Bitman · · Score: 2, Interesting

    it would be nice to see, rather than just plain chroot with its own directories and such, a 'chmod jail', which acts as a symlink to other directories (no need to copy libs) yet makes certain alterations impossible for any user (even root)

    --
    -- 'The' Lord and Master Bitman On High, Master Of All
  5. Real jail for Linux by j7953 · · Score: 3, Interesting

    Note that there is a project that attempts to add jail-syscall-like functionality to the Linux kernel: vserver.

    I haven't tested it yet, but it looks very promising.

    --
    Sig (appended to the end of comments I post, 54 chars)
    1. Re:Real jail for Linux by gelinas · · Score: 4, Interesting
      The vserver projet provides a more general solution
      than jail (2 syscalls instead of one). It also builds on
      linux capabilities, so you can control the level of
      privilege a virtual server has (root in a vserver).
      Because of its generality, it was far easier to package
      solutions out of it. vserver is already in production today.
      Some ASP offers virtual servers to customer.
      Quite frankly, once you have tried vservers, it changes the way you work (for the better). Here are some advantage:

      • As fast as the native server
        -More secure. A vserver can't break into the root
        server.
      • A vserver containing a pretty full linux distro uses
        30-40megabytes of disk space.
      • Cloning a vserver takes one minute. So having
        a production server running side by side with a
        clone so you can test upgrades is easy and safe.
      • A vserver may be moved from one physical server
        to another without reconfiguration.


      To say that vserver is promising is ... missleading :-)
  6. System call policies by Phactorial · · Score: 4, Interesting

    The Medusa project allows the implementation of system call policies in Linux. Google for it. I think with smart rulesets; chroot and jail are all redundant. For example, denying untrusted user set*id access (toppled by smart fileaccess privileges) renders most "security" attacks useless for that user (he cannot cause any real damage other than DoS, which can also be stopped by implementing thread/fork timers for that user).

  7. Is IA32 any less secure? by Anonymous Coward · · Score: 1, Interesting
    Hi all. I may be remembering incorrectly but I think I heard that there existed assembly level vulnerabilities specifically for IA32 (x86) CPUs running certain OSs. In other words, there are CPU hardware design flaws that a user can exploit via certain asm instructions in order to gain privilege to the OS. This would be a roughly similar concept compared to the way an attacker can find a way to gain a UID 0 shell and then break out of chroot. Is this possible, or just urban legend?

    If this is possible, then this would diminish the value of even kernel level ACLs on files and processes. For example, grsecurity and LIDS.

    BTW I just followed the instructions listed in another comment in this discussion in order to break out of my own chroot instantly. Wow. :-/ Well at least it's still fine as long as there's no way to gain UID 0 privilege inside a chroot, such as if the network daemon runs as non-UID0 and there are no userspace tools in the chroot.

  8. chmod is nice... by Squidgee · · Score: 2, Interesting
    But, it's not perfect. As stated by another user, it's the equivilant of putting 10 padlocks on the door, but leaving the window wide open. Here is an article about how easy it is to break chroot in a CGI based server.

    So, while chroot may be good, do not rely on it soley for security.