Why jail?

To make long story short, in a unix environment there is a chroot operation. It allows to change the apparent disk root directory for the current running process and its children. A program that is re-rooted to another directory cannot access or name files outside that directory, and the directory is called a “chroot jail”.
It was introduced very long time ago and still exist as part of many systems (implementation and number of features vary, though). The chroot system call was introduced during development of Version 7 Unix in 1979, and also added to BSD by Bill Joy on 18 March 1982 — 17 months before 4.2BSD was released — in order to test its installation and build system.
This was one of the first attempts, to make virtualized environment encapsulated inside real system.

Let’s add some details?

chroot() is a Unix system call that is often used to provide an additional layer of security when untrusted programs are run. The kernel on Unix varients which support chroot() maintain a note of the root directory each process on the system has. Generally this is “/”, but the chroot() system call can change this. When chroot() is successfully called, the calling process has its idea of the root directory changed to the directory given as the argument to chroot(). For example after the following line of code, the process would see the directory “/foo/bar” as its root directory.
Most importantly, due to the change in the root directory, the area which a chroot()ed program lives in will require various files and programs for sane operation. For example, a perl requires a very large number of files and directories to work within a chroot()ed environment – 2610 files and 192 directories for a reasonable installation, thus the more complex and larger a program gets, the more support files it will use.

I’m not a prisoner! Let me out!

Now we almost near the topic of this post. Whilst chroot() is reasonably secure, a program can escape from its trap. So long as a program is run with root (ie UID 0) privilages it can be used to break out of a chroot()ed area. And if an attempt would be successful, it would be called a jailbreak.
Essentially, a simple general algorithm to commit a jailbreak from chrooted environment would be something like this:
1) Create a temporary directory in its current working directory
2) Open the current working directory
only required if chroot() changes the calling program’s working directory.
3) Change the root directory of the process to the temporary directory using chroot().
4) Use fchdir() with the file descriptor of the opened directory to move the current working directory outside the chroot()ed area.
only required if chroot() changes the calling program’s working directory.
5) Perform chdir(“..”) calls many times to move the current working directory into the real root directory.
6) Change the root directory of the process to the current working directory, the real root directory, using chroot(“.”)
Once the above has been done, the program can run functions as required. A natural function would be to exec() a command interpreter like sh over the current program.

Am I free?

Nowadays, jailbreak is used mainly to describe to process to unlock the iPhone (or any other similar smartphone) and gain the root privileges. General idea is the same, however method are different, because developers close existing exploits and change system settings frequently, and “jailbreakers” on the other side are working hard to find new holes and exploits.
Conclusion is simple: it is always a benefit to know the history of certain thing happen in the real-time, because without past there is no future…