Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
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
    
@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. –  Aleksandr Makov 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

2 Answers 2

up vote 7 down vote accepted

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.

share|improve this answer
    
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. –  Aleksandr Makov Dec 4 '12 at 12:56

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.

share|improve this 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. –  Aleksandr Makov 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? –  Aleksandr Makov 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

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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