2

I've Debian Squeeze running and setup a chroot environment (/jail) with debootstrap.

As seen in a tutorial, I mounted the following:

proc on /jail/proc type proc (rw)
devpts on /jail/dev/pts type devpts (rw)

Within the jail, i've running an additional sshd on a different port as the "parent" system.

So far, all is working fine and as expected.

But I just noticed, that i am able to change the host IP address from within the jail. Is this a normal behaviour? I tought, that the chrooted environment cannot change things on the "real" system? But after changing ip address and running

/etc/init.d/networking restart

the system was only reachable via the new ip address.

Please can someone explain, why this behaves like it does? Is there a way to prevent this? So that everything within the jail, "stays in the jail"

Thank you very much in advance.

Casper

casper
  • 519
  • 2
  • 6
  • 12

1 Answers1

3

chroots ONLY change the visible root of the filesystem for child-processes of the chroot-ing command. Everything else - sending signals, manipulating the kernel, etc- is unaffected. It quite simple to leave the chroot again, if it is the only security you have in place.

Take a look at LXC, Linux-VServer or OpenVZ for proper containers in Linux, that do protect from more than accidental directory traversals.

David Schmitt
  • 2,185
  • 2
  • 15
  • 25
  • 1
    +1 for OpenVZ. OpenVZ has "virtualized" network so the guest (think of jail) can have different IP address. FreeBSD has jail which is like openvz. Linux chroot != jail (in the sense of freebsd). – cstamas May 24 '11 at 18:28
  • Correct me if I am wrong. But it's still quit harder to get access to files outside the chroot via a possible exploit in sshd running in a chroot instead of running the sshd without chroot? – casper May 24 '11 at 20:21
  • @casper: as soon as you're root, you're not confined by the chroot. It MAY be that scripts won't try to escape, but nevertheless the whole box is compromised. – David Schmitt May 24 '11 at 21:11
  • Usually you only need to mknod the device of the root fs and mount it somwhere. Voila! – David Schmitt May 24 '11 at 21:11
  • Okay, thank you for the information so far!! What about running sshd as a non-root user within the chroot? Then any concerns? – casper May 25 '11 at 17:17
  • There are many ways a chroot can be compromised even from a non-root uid (e.g. talking to processes of the same uid outside the chroot or subverting the kernel). To put it bluntly, if you have to ask, then a chroot will not give you additional benefits beyond the protection you already have through the non-root uid. Please take a look at a proper jailing solution. They are not hard to setup and actually reduce the attack surface within the jail to (almost) only the kernel. – David Schmitt May 25 '11 at 17:26