I've been playing around with CentOS box for couple of years now. So I'm pretty comfy with terminal. However, I read a lot of blog-post claiming that chroot is insecure and amount of those posts frightens. Is it really so? Why?

I use chroot to lockdown the SFTP-only users in specific context, without any shell or commands at all. So really, what is the security problem with that?

Question is exiled from StackOverflow.

  • 1
    First: The question hasn't been closed/migrated on Stack Overflow, but it is clearly OT there. The appropriate action would be to wait until it is migrated or flag it and ask a mod to do it, not cross-posting it on another site. But second: If you "play around with CentOS", you are wrong here as well. This site is for professional system adminstrators, not hobbyists - please see our FAQ.
    – Sven
    Dec 4 '12 at 12:00
  • 2
    @SvenW thanks, I'll keep in mind your tip for the future. And about the 'second', well, sorry, but I do not see how my question violates the FAQ. After reading it twice now, I can say it doesn't. As of phrase "play around with CentOS", well, I thought it's quite obvious that chrooting and SFTP-only users and being considered about the security is a very serious topic that professionals can benefit from as well in their corporate or in any other "professional" environments. Dec 4 '12 at 12:48
  • 1
    @sven in case you didn't know, SF has been removed from SO's migration list because of how many bad questions they send us.
    – MDMarra
    Dec 4 '12 at 12:51

Because, in most instances, a root process can easily exit the chroot. This is by design, as chroot was never intended as a security device.

Alan Cox somewhat famously berated a developer that submitted a kernel patch to "fix" this behavior, claiming that chroot has been abused as a security device, but was never intended to be one.

  • Perfect! Thank you very much. So this is the matter of root processes that are present in the root or are accessible from it. Thanks. Dec 4 '12 at 12:56
  • I've just verified it that by running the C program shown on unixwiz.net/techtips/mirror/chroot-break.html as root on Linux 4.18 it's possible to escape the chroot.
    – pts
    Jan 4 '19 at 16:35
  • So don't hand out root privileges. Even regular "secure" systems have root accounts. Sep 18 '19 at 12:05

I know at least one example of why it is considered to be insecure. A chroot environment /proc isn't isolated, so it's fairly easy to access resources not owned by processes started in your chroot.

Using a chrooted enviroment for SFTP is fine and improves the level of security significantly. Just don't abuse it as container-based virtualization, which does provide more levels of security. In this, I underline what's in @MDMarra's answer.

  • Thank you. So now it becomes more clear, that chroot itself isn't poor on security but rather it's security depends on the environment where it is set up. Dec 4 '12 at 12:54
  • Actually, chroot isn't poor on security, because it was never intended to be a security device. It was meant to be a development tool for running multiple versions of the same binaries side-by-side with different dependencies. It's not a substitute for properly securing services - though it can be helpful in certain circumstances as long as you understand what it is and what it isn't.
    – MDMarra
    Dec 4 '12 at 12:58
  • MDMarra, so basically, chroot isn't meant to be used for capturing SSH connections. Then, in your opinion, does "chrooting the incoming SSH connections" sound somewhat unprofessional to you and should it be avoided? Dec 4 '12 at 13:05
  • No, not necessarily, just realize that any exploit that could lead to privilege elevation or any process running as root in the chroot would be trivial to break out of. It can certainly be a piece in the puzzle, but it shouldn't be the whole thing.
    – MDMarra
    Dec 4 '12 at 13:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.