4

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?

Avery Payne
  • 14,536
  • 1
  • 51
  • 88
  • 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 04 '09 at 09: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 04 '09 at 09:57

7 Answers7

8

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.

David Pashley
  • 23,497
  • 2
  • 46
  • 73
  • +1 for both proof-of-concept and for explanation. – Avery Payne Jun 04 '09 at 07:01
  • 2
    Not to forget http://linux-vservers.org, a jail-like implementation for Linux – David Schmitt Jun 04 '09 at 08:54
  • 1
    chrooting to parent dir only works if attacker gets root inside the chroot. You normally drop root privs after chroot() – Thomas Jun 04 '09 at 09:40
  • Never assume an attacker won't be able to get root – David Pashley Jun 04 '09 at 11:35
  • 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 04 '09 at 13:27
  • Actually if the daemon runs as root then the shellcode will usually break out of the chroot before spawning a root shell. So chroot barely adds anything there. You don't need perl, you can just do a one-shot. But for non-root daemons the shellcode would have to exploit the kernel itself to break out of the chroot. – Thomas Jun 04 '09 at 14:34
  • Which is why you shouldn't run a chrooted application as root - at least not for security reasons. – sh-beta Jun 04 '09 at 15:58
  • 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 04 '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 09 '09 at 01:31
3

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.

therek
  • 682
  • 5
  • 6
2

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.

Thomas
  • 1,476
  • 11
  • 16
1

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.

Zoredache
  • 130,897
  • 41
  • 276
  • 420
0

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.

Antoine Benkemoun
  • 7,314
  • 3
  • 42
  • 60
0

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.

Bernd Haug
  • 888
  • 5
  • 12
  • Am I the only one who thinks VMs are not the answer due to management, IO and code overhead? – Jé Queue Nov 26 '09 at 04: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 http://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 07:52
0

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.

sucuri
  • 2,867
  • 1
  • 23
  • 22