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 would like a definitive answer as to why this practice should be pursued with services that are exposed to potentially hostile network(s) (i.e. the Internet). As I understand it, there is a method for breaking out of a chroot jail, so if there is no real value to this security measure, then why are some installations still pursuing it?

share|improve this question
    
Worth it to whom? Worth it in what specific conditions? I don't see how you can have a "definitive answer" on something that's clearly a matter of evaluating trade-offs. –  bignose Jun 4 '09 at 9:28
    
Either it provides usable security increases, or it doesn't. Here, I'll change the title a bit to clean it up... –  Avery Payne Jun 4 '09 at 9:57

7 Answers 7

up vote 8 down vote accepted

You should never consider a chroot a complete security feature. While is makes attack harder, if you do manage to get some control inside the chroot, it is fairly easy to break out of. There's a method involving chrooting to a parent directory (..) More info here. The reason that chroot gives some security benefit is that many of the applications that a hacker might expect to have around just won't be there. If given the choice between something being chrooted or not chrooted, I'd pick the chrooted option.

A better approach would be something like BSD's jail, Solaris's zones or some virtualisation technology like KVM or Xen. These approaches take the same compartimentalisation idea that chroot does and makes them stronger. You could also look at something like SELinux, but this is slightly more complicated, and therefore prone to mistakes.

share|improve this answer
2  
Not to forget linux-vservers.org, a jail-like implementation for Linux –  David Schmitt Jun 4 '09 at 8:54
1  
chrooting to parent dir only works if attacker gets root inside the chroot. You normally drop root privs after chroot() –  Thomas Jun 4 '09 at 9:40
1  
Of course not, but your statement "it is fairly easy to break out of" is very misleading. The hack you linked to requires root privileges and a C compiler or Perl interpreter. Chrooting an application that runs as root is like firewalling inbound Netbios but allowing everything else. And why on earth is there a Perl interpreter or C compiler in your chroot? The only thing there should be the app's data files and possibly a logging socket. Chroot is imperfect but, properly setup, makes breaking an app harder and mitigates the post-breakin damage. –  sh-beta Jun 4 '09 at 13:27
1  
You don't need a compiler in the chroot, you just need to be clever. Getting out of a chroot via an application that isn't running as root involves abusing buffer overflow to overwrite the stack, to jump to more code you've injected into the process via the buffer overflow, which takes advantage of an unpatched kernel bug that gives you root privileges and then does the chroot escaping code. Hard, yes, but not impossible and all fairly common attack methods. –  David Pashley Jun 4 '09 at 20:15
1  
Of course it's not impossible, but this means that you need an exploit in the application and then an exploit in the kernel given the tools you've got inside the chroot. I agree that chroot is not a silver bullet, but it's not easy to break out of and is a very significant component to securing any application. –  sh-beta Jun 9 '09 at 1:31

As I understand it, there is a method for breaking out of a chroot jail (...) then why are some installations still pursuing it?

You can say the same thing about passwords. The point is that quite often securing some resources means placing so many obstacles on intruder's way to force him to give up before reaching the target. You can't rely on a single method to secure given resource. Furthermore, chrooting gives you more control over an application you're running. You can restrict file system resources this app have access to.

share|improve this answer

Yes it does.

  • If your daemon or whatever is providing the service does not run as root then even a hole in that daemon is isolated from the rest of the system.
  • If your OS can restrict operations that can be done while chroot()ed, it's even better. grsec-patches to Linux for example can remove ability of the root user inside a chroot to break out, or create /dev-nodes inside the chroot

If, however, you get an exploitable kernel bug (or just a root hole if not grsec or BSD jails) inside the chroot, then the whole system is owned. Not so if you run a real virtualizer (such as VMWare, but NOT BSD jails. They don't help since they use the same kernel for all "systems").

So yes, it adds a security layer, if used correctly.

share|improve this answer

So if there is no real value to this security measure, then why are some installations still pursuing it?

There may not be much security gained, but in some cases you make the system easier for the user. If they are not distracted by all the other stuff they don't need to see, they may find the system easier to use.

share|improve this answer

I find chroots to be way to complicated and have never been able to install one. One could argue that if I had been able to do so, I would find great interest in it but I still haven't.

I think that isolating your services in virtual machines (on Xen of course, but VMWare will work too if you insist :-P ) is a much better idea considering the computing power available these days. Virtual machines also have the huge advantage of being really easy to backup/migrate which chroots do not have. You also have comprehensive interface for managing VMs, which you definently don't have for chroots.

share|improve this answer

Don't run chroots when you can run jails/zones/openvz for pretty much the same effort and overhead, and have a much more standard-looking, more isolated environment.

Chroots used to be a good idea for non-root user services when nothing better was available, but are passé now.

share|improve this answer
    
Am I the only one who thinks VMs are not the answer due to management, IO and code overhead? –  Xepoch Nov 26 '09 at 4:32
    
Depends. First of all, I suggest OS-specific isolation, which is generally very low overhead. But on VMs: IMO, VM deployment/maintenance is no biggie if you have automated setup and centralized policy mechanisms, e.g. FAI and puppet for Debian/Ubuntu or WDS and Group Policy for Windows... IO overhead can be problematic (cf blogs.sun.com/JeffV/entry/virtual_overhead), but I see servers idling more than getting bogged down. Of course, VMs are no silver bullet... Re: Code overhead, I don't know what you mean. –  Bernd Haug Jan 13 '10 at 7:52

Chroot adds a lot of security benefits and you can only break it if you are root. So you are raising the bar for what an attacker needs to do.

Plus, chroot provides an application isolation, while virtualization provide operating system separation. So you can run, for example, apache inside chroot on a virtual machine.

share|improve this answer

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.