Clarification: "Jail" -vs- "Chroot"

[Aiza]

Ed Flecko wrote:
> Hi folks,
> I'm reading about "jails" and "chroot", and I'm not clear about the
> differences so I'm hoping someone can clarify this for me.
> 
> Here's what I "think" is correct:
> 
> 1.) FreeBSD has both "chroot" capability as well as "jail" capability.
> 
> 2.) Only FreeBSD has true, "jail" functionality? Yes?...No?
> 
> 3.) When reading something (book, article, etc.), is there a way to
> determine if the author is, in fact, talking about truly a "jail" or
> are they really just referring to a "chroot" environment? For example,
> I have a book ("Preventing web attacks with Apache") that says:
> 
> "Chroot is short for change root and essentially allows you to run
> programs in a protected or jailed environment. The main benefit of a
> chroot jail is that the jail will limit the portion of the file system
> the daemon can see to the root directory of the jail. Additionally,
> since the jail only needs to support Apache, the programs available in
> the jail can be extremely limited."
> 
> 4.) Jail is the more secure of the two options?
> 
> 5.) When would you "typically" use a jail -vs- a chroot? The new, 2nd
> edition of "Absolute FreeBSD" says:
> 
> "Chrooting is useful for web servers that have multiple clients on one
> machine—that is, web servers with many virtual hosts."
> 
> Comments??? Suggestions???
> 
> Thank you!
> 
> Ed

Well let me take a shot at this. First of all we are only talking about 
the FreeBSD operating system. The ability to chroot a directory tree has 
been available since RELEASES 2.0. The jail utility first appeared in 
RELEASE 4.0. The jail utility is just a basic effort to automate the 
building and administration of an chrooted directory tree which is 
pretty much useless unless it contains a complete copy of the Freebsd 
operating system binaries. The major short coming of the jail command 
jail system is each jail has it's own copy of the hosts running system 
binaries. Freebsd reserves a limited number of control structures for 
storing files and directories, called inodes. Creating a few jails 
consumes many of these valuable inodes, eventually preventing the 
creation of new jails and new files on the host. Worst yet is each jail 
loads it's own copy of it's running binaries into memory which causes 
thrashing on the swap device as memory pages are swapped in and out as 
the limited memory is shared between the host and jails. Besides 
consuming resources and creating performance degradation, this also 
causes a major administration headache when wanting to update the host 
running system, because the host and the jails all have to be running 
the same RELEASE version.

Now with some considerable hand jobbing per the jail section of the 
handbook, a jail environment can be created where by a single copy of 
the jailed running binaries are shared among all the jails. But this 
still leaves you with an administration nightmare as the number of jails 
deployed grows past 5. Now there are some ports in the port system that 
are utility wrappers around the jail command that tries to address this 
administration nightmare. My experience with these are they are very 
poorly documented and you really need to have a good grasp on how jails 
work and network ip address usage before they are useful. Their easy of 
use quickly evaporates as the number of jails deployed reaches 10.

The next generation of a jail utility for the deployment of a large 
number of jails is in project phase right now. Keep checking the ports 
system for qjail.

Now about what to run in a jail. Well since each jail is like a complete 
stand-a-lone operating system, you can populate it with any application 
you want. The real limitation is how is that jail going to gain public 
internet access so the domain name of your apache website can be found 
and accessed. A static ip address is pretty much required, though with 
some creative ip address assignments this can be circumvented. Thats a 
whole other subject area.