Slashdot Mirror

← Back to Stories (view on slashdot.org)

Chroot in OpenSSH

Posted by ScuttleMonkey on from the making-life-easier-always-my-goal dept.

bsdphx writes "OpenSSH developers Damien Miller and Markus Friedl have recently added a nifty feature to make life easier for admins. Now you can easily lock an SSH session into a chroot directory, restrict them to a built-in sftp server and apply these settings per user. And it's dead simple to do. If you need to allow semi-trusted people on your computers, then you want this bad!"

11 of 62 comments (clear)

  1. Why bother? by whoever57 · · Score: 3, Insightful

    Didn't we just read that chroot "jails" are not secure?

    --
    The real "Libtards" are the Libertarians!
    1. Re:Why bother? by bsdphx · · Score: 5, Insightful

      Understanding the issues is better than parroting what you've heard from random sources. Given the OpenBSD and OpenSSH track record for security it's obvious they have some serious clues about security.

    2. Re:Why bother? by Wesley+Felter · · Score: 3, Interesting

      Didn't we just read that chroot "jails" are not secure? I've read those arguments and find them confusing. Sure, root can break out of a chroot, but what about non-root users?
    3. Re:Why bother? by illegibledotorg · · Score: 5, Informative

      Giving someone a shell and putting them in a chroot crafted to look and function like a full system is one thing.

      Giving someone an SFTP session and chrooting them into a subdirectory is another thing.

      The feature added in this commit was arguably intended for the latter purpose given the additional changes to the SFTP subsystem that were included. There are countless tutorials and patches and scripts that are available to achieve chrooted SFTP-only access, but now it's been implemented in the core of OpenSSH. In my eyes, this solution is not only a "cleaner" solution to the problem, but it's probably more secure too.

    4. Re:Why bother? by jandrese · · Score: 4, Informative

      They are probably better than giving semi-trusted users full filesystem access, even if they aren't perfect security. It's not even that chroot is inherently broken, it's just that people were using it incorrectly (setting it suid or letting the user become root inside of their jail). Most of the complaints seem to be "the user managed to get root and broke out of the jail", which is a problem with whatever allowed your user to become root in the first place, not the jail itself.

      Basically, to break out of a chroot you need to be root. If you're root, then you've already defeated the security on the box anyway. Don't let untrusted users become root.

      --

      I read the internet for the articles.
    5. Re:Why bother? by parcel · · Score: 4, Informative

      Didn't we just read that chroot "jails" are not secure? You may want to take a look at http://www.openbsd.org/faq/faq10.html#httpdchroot, especially the section titled "Should I use the chroot feature?".

      I imagine something similar would be forthcoming regarding OpenSSH specifically.
    6. Re:Why bother? by jjohnson · · Score: 3, Informative

      They're not secure for root users. That was the issue identified in the recent "read" you mention--someone was pointing out that root can break out in a particular way, and the kernel devs responded that 1) that was by design, and 2) locking that down left an infinite number of other ways to break out if you're root.

      For regular user accounts, a properly configured chroot jail is still a very useful security tool.

      --
      Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
  2. FTP servers have been doing this for years by caseih · · Score: 3, Informative

    The purpose of this feature doesn't seem to be to restrict what a shell user can do. Rather, if I read this correctly, it restricts what files a user can access via sftp. Without this feature, a user can sftp in, and then cd to / or any other folder that he has rights too. This chroot feature lets the admin limit the root to, say, his home directory, or some other folder such as a virtual web root or something.

    It's only natural that this same chroot feature would be added to sftp.

  3. all that for sftp? by sgt+scrub · · Score: 3, Interesting

    It is cool tech but not the way I would do things. WebDav with ApacheSSL properly installed is lots safer. IMHO there should never be user accounts on a machine, other than root and the person administrating the box.

    --
    Having to work for a living is the root of all evil.
    1. Re:all that for sftp? by evilviper · · Score: 3, Insightful

      WebDav with ApacheSSL properly installed is lots safer.

      Why? No privilege separation. A MUCH bigger code base.

      Not to mention fewer standalone programs.

      IMHO there should never be user accounts on a machine,

      Why not? The user security model is reliable and time tested. It does not require reinventing the "user". It does not depend on one program handling it's own system of virtual permissions correctly. It does not depend on the security of a large program that users directly interact with.

      I can see ample reasons sftp is safer.
      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
  4. Re:Tell us more. by sjames · · Score: 4, Informative

    In the right circumstances, 2 non-root users can conspire to break out of jail if one is chrooted below the other.

    Let's say A is chrooted to /home/sorta-trusted and B to /home/sorta-trusted/not-so-much.

    A diropens his / and creates a unix socket in /not-so-much. B opens the socket in his /. Now, A passes his fd to his / to B. B then does fdchdir on the fd and he's out of jail. Now B can break A out.

    The moral is, never use nested chroot jails!