2010-03-23 сhroot still can be broken. Why?

English Soapbox
#1

Hello.

Just read WiKi’s article about “second chroot” issue.
Here is the full source. Checked this chroot break script on my OpenSuSE 11.2 x86-64 and see it works perfectly.

You can also check.

  1. Create chroot env with make_jail.sh update.
  2. Compile and copy “chroot breaker” to /home/jail/bin/jb
  3. Run chroot and jb
    chroot /home/jail
    ls # jailed now
    jb
    ls # free now

So my question: why chroot still broken in MODERN linux kernel?
Why it is not fixed yet?

#2

You’re using the wrong tool for the wrong job but I note …

Where non zero UID is the UID the user should be using. This should be a value other than 0, i.e. not the root user. If this is done there should be no way to gain root privilages unless an attacker uses something within the chroot() jail to gain those privilages.

Then from wiki …

in order to test its installation and build system

What you really want is … FreeBSD jail - Wikipedia, the free encyclopedia has linux variants.

#3

Yes, you are right, but Linux doesn’t have jail AFAIK.
Virtualization is heavy weighted, chroot looks like most lightweighted solution. So why chroot is not fixed?
Any thoughts?

#4

It’s not designed to be secure against a root process.

#5

There was some kernel patches that assisted this but had networking problems, so wasn’t accepted. As far as I can tell the vserver patch set was the answer.

You also have some kits i.e jailkit on OBS that should assist with trad chroots.

Its you that claims it is broken(So maybe explain why, chroot was never designed from a security point of view) but it works fine with its limits and from what I can see even vserver is using some elements to sandbox.

There is plenty of solutions for your problem. If you wish to use a chroot then I guess it is up to you to enable the environment so that a root account can’t be acquired.

#6

Thank you, that is perfect answer.

For my cause PHP’s openbasedir and SSH’s ChRootDirectory seems sufficient.

#7

For my tuppence I wouldn’t be trusting php in a chroot.

A quick google got me this Gentoo Linux Documentation – PHP: Multiple vulnerabilities should of been a correction rather than root account should of been privileges.

My conclusion is you’re trying to put a web server in a chroot. For me as I lack the skills I would be looking at putting the whole thing in a DMZ with a good back up policy and data servers behind the firewall with a pinhole.(You can’t secure a shed in the prison yard)

Not to mention php has many attack vectors. Now Ken more than likely has the skill sets but even then I’m not sure he would resort to a chroot.

Anyway my tuppence far from knowing…