Chapter 16 Jails

Contributed by Joseph J Barbish

Table of Contents

16.1 Synopsis

16.2 Introduction
     16.2.1 What is a Jail Cell
     16.2.2 What is a Jail System
     16.2.3 The Three Jail Cell Definition Methods

16.3 How to Build the Jail System
     16.3.1 Building the Jail System Filesystems
     16.3.2 Creating & Deleting Jail Cell Filesystems
     16.3.3 Enabling Jail Cell SSH Support

16.4 The jail.conf Method
     16.4.1 jail.conf Definition Statements
     16.4.2 Creating & Deleting the jail.conf jail cell Definition File
     16.4.3 Starting & Stopping jail.conf jail cells
     16.4.4 Boot Starting & Shutdown Stopping of jail.conf jail cells

16.5 The Modern rc.d Method
     16.5.1 rc.conf Definition Statements
     16.5.2 Creating & Deleting the rc.conf jail cell Definition file
     16.5.3 Starting & Stopping the rc.conf jail cells
     16.5.4 Boot Starting & Shutdown Stopping of rc.conf jail cells

16.6 The Legacy rc.d Method
      16.6.1 Starting & Stopping of Legacy rc.d jail cells

16.7 Working With Jail Cells
16.8 Summary of the provided Scripts & Their Usage
16.9 Jail Cell Network Traffic Flow
16.10 How to download the script tar file



16.1 Synopsis

Time is money, So to shorten the time used to deploy a jail system, this Jail Chapter has been written using included scripts as examples and includes supporting information where it's used instead of pointing the reader to other external references. New concepts and terminology are introduced to clarify how the incarceration process is achieved using the jail function.

A jail system is too complicated to explain by giving the manual commands to issue from the console command line. Instead what is shown is script code that can be copied and pasted into a file and used as is. Many parts of the script logic have no equivalent console command line commands. The scripts are broken down into logical functions that follow the logical functional progression for first building the jail system filesystems, creating the jail cell filesystems, creating the modern rc.d or legacy rc.d or the jail.conf definition statements files, followed by the starting, stopping and deleting of jail cells defined for each of those jail cell definition types.

These scripts are not to be though of as the only way of implementing jail systems. They are intended to demonstrate to the reader the concepts expressed in this Chapter. The reader may use them as they are or modify them to their own needs.

All the scripts documented in this Chapter can be downloaded as a single tar file.
See 16.10 How to download the script tar file for instructions


This chapter explains what the FreeBSD jail system is and how to utilize one.

Previous to 9.1-RELEASE jail systems were implemented utilizing the rc.d script method. With 9.1-RELEASE an second method of jail configuration and control became available using the jail(8) program that introduces the /etc/jail.conf configuration file. It includes new extensions to enable special functions on a per jail basis.

After reading this chapter, you will know:


Other sources of useful information about jails are:


16.2 Introduction

This introduction is not intended to be a historical  review of the FreeBSD jail concept. It's purpose is to expose the reader to the two legacy generations of how FreeBSD jails were commonly used based on the computer hardware available at the time and introduce the third generation jail system solution.

The original FreeBSD developers felt the need for a method to restrict a processes access to the host system resources so if it becomes compromised the host system is protected from also being compromised. They achieved this goal with the "chroot" command which was in the original 4.4BSD system, from which the current FreeBSD RELEASE is a direct descendant. This first generation "chroot" environment, made it look like the named directory was the "root" IE: starting point; of a operating system directory tree. Just like "/" is today in FreeBSD. The "chroot" environment shared the hosts network and disk space. This trait continues into today’s jail systems.

In this basic incarnation, the "chroot" directory tree would only contain copies of the host's operating system binaries that were necessary to form a very simple running environment for a single application such as a apache web server. It took a host administrator with advanced knowledge and understanding of the operating system modules and the userland application to configure and setup such a "chroot" environment. This is still true today if such a jail is desired. At that time the maximum disk drive size available was 300MB and maximum memory size was 64K and the maximum cpu speed of 8mhz. These limited resources caused very poor host "chroot" environment performance and made the "chroot" concept unpopular. As you can imagine, occupants of these basic "chroot’s" influenced host administrators to stay at the RELEASE version they were at because of the size of the task to redevelop their "chroot" environment under a new RELEASE versions binaries.


The rc.d/jail script appeared in FreeBSD 4.0. With this second generation "chroot" enhancement came the renaming of a "chroot" environment to a "jail", the ability to assign IP address to a jail, auto starting jails at boot time, and a general shift in thought about the occupant of the jail. The first generation simplistic "chrooted" directory tree apache web server that had no easy way to be configured, progressed into a complete clone of the host's operating system with all the customizing options one is familiar with on the host. The "make buildworld" method of creating the jail filesystem was the bases of the second generation and is commonly used even today. The major shortcoming of this type of jail system at that time was each jail had its own copy of the hosts operating system binaries. Do no confuse "operating system binaries" with kernel bootable binaries which jails do not use. FreeBSD reserves a limited number of control structures for storing files and directories based on available memory size called inodes. Creating a few jails consumes many of those valuable inodes, eventually preventing the creation of additional jails. Worse yet, each jail loads it's own copy of the complete operating systems binaries into memory, this causes thrashing on the swap device as memory pages are swapped in and out as the limited memory is shared between the host and the jails. At this time the maximum disk drive size available was 1GB and maximum memory size was 256K and the maximum cpu speed of 64mhz. Besides consuming large amounts of the limited resources and creating performance degradation, this also causes a major administration headache when wanting to update the host operating system, because the host and the jails have to be running the same version of the operating system binaries.

With RELEASE 5.4 the newly enhanced nullfs command added the ability for jails to share a single set of the operating system running libraries between themselves. This third generation solution solved the performance problems of the second generation, but had its own problems. Setting up a third generation jail system was an undocumented manual one. Even as of 9.1-RELEASE the documentation only shows the "make buildworld" method of creating the jail filesystem. The manual administration of this jail system became increasing difficult with each additional jail.

With today's top end computers of 8 or 16 cpu cores, 256gb of memory and 3tb disk drives, the limited resources of the past are gone forever. Computers running thousands of jail are possible. An first generation jail system with it's userland application is still available to any host administrator having the ability to create one, but it's impossible to find any documentation about it and for all practical purposes its a dead subject.

The third generation solution separates the second generation single jail filesystem into two filesystems. The "sharedfs filesystem" now contains all of the operating system's executable libraries as read-only files and is mounted as an "nullfs" that is shared between all the individual filesystem directory tree jail cells. The "jail cell filesystem" just contains the operating system configuration files plus the userland occupant, which can be a server application or any of the available ports. This design effectively secures all the executable files from being updated or deleted and also secures the directories containing the executable files from having new files inserted by any user running inside of the jail cell.

Jail systems are a very powerful security tool for system administrators. They provide a method to compartmentalize services that are exposed to the public internet so the host environment is protected from becoming compromised if the jail cell should become compromised due to exploiting by a public attacker. Jail systems are also useful in protecting the host from malicious actions on an Local Are Network. Their basic usage can also be useful for advanced users with special needs.



16.2.1 What is a Jail Cell

A jail cell is a single compartmentalized directory tree structure that for all purposes, acts and behaves just like a computer running the FreeBSD operating system. Viewed from the public Internet or from the Local Area Network it's almost impossible to distinguish any difference between the two by everyone except maybe an expert technical attacker. A jail cell can be assigned a public routable IP address and receive unsolicited inbound requests for service, such as for a website being run by apache or a email server running postfix. If a jail cell were to become compromised by a public attacker taking advantage of  exploits  in the jail cell's running applications, most intruders would by unaware they are confined in a jail cell and any damage to the jail cells changeable configuration files content would have no effect on the host running the jail cell. The jail system shares the hosts disk space and the hosts network stack. All IP traffic passes through the host's network stack first and only the host's firewall can interrogate the traffic. This means that jail cells can't have their own firewalls. The only requirement of the jail system, is the running operating system executable libraries shared with the jail cells must be the same level as what the host is running.

The jail cell's ability to mimic a computer running the FreeBSD operating system is it's core advantage. This ability has many uses for an creative system administrator other than the security of public accessible services.



16.2.2 What is a Jail System

Multiple compartmentalized filesystem directory tree structured jail cells all sharing a single read only nullfs mounted filesystem containing a single copy of the operating system executable libraries is the primary design concept of the jail system documented here and comprises the  third generation jail system solution.

The jail system is comprised of two components:

1. The building of the jail system's  physical directory tree filesystems that forms the bedrock of this third generation solution,  which is defined by;

2. The jail cell control component which comprises the creation of the jail cell definition statements, starting and stopping of the defined jail cells by the host system.



16.2.3 The Three Jail Cell Definition Methods

Previous to 9.1-RELEASE all jail cells were based on jail cell definition statements being placed in the host's /etc/rc.conf file and manual start / stop control accomplished using /etc/rc.d scripts launched by the "service jail" command, with the option of auto boot time startup. This will be referred to as the legacy rc.d method.

With 9.1-RELEASE a second method became available, the jail.conf file method. It's based on the /etc/jail.conf file. The syntax of the jail cell definition statements in the jail.conf file is totally different from those used in the rc.conf file of the legacy rc.d method and the method of jail cell start / stop control  is now accomplished by the jail(8) command instead of using /etc/rc.d scripts launched by the "service jail" command. This new method allows far greater flexible in controlling the location and usage of the jail cells definition files and provides many parameters that can be applied on an per-jail cell basics.

The modern rc.d method has divorced it self from relying on the "service jail" command for starting and stopping and no longer do the rc.conf jail cell definition statements have to reside in the /etc/rc.conf file. They can now reside anywhere on the host's filesystem. This is basically the same freedom the jail.conf file method provides.

These three jail cell definition methods can be used together or separately because the jail system scripts have been designed to allow it. The jail system organizational design produces the Third Generation jail solution and these three jail cell definition methods all share that jail system.



16.3 How to Build the Jail System

The jail(8) manual page plus all the other jail documentation found by an Google search make the incorrect assumption that all users of the FreeBSD Operating System, installed the system sources and use the "make buildworld" method of maintaining their host systems. As a result, potential jail system users were forced to install the system sources and perform the time consuming compiles the "make buildworld" process requires just to be able to populate their jail system.

A faster method is available which does not rely on system source files. All RELEASE versions of FreeBSD have compressed install files available for download. The "pristine" method  is based on using one of those official compressed install files as source for populating the jail system with an pristine copy of the operating system. This method provides an added level of security over the "make buildworld" process, where intentionally or un-intentionally modified executables could populate the jail system. This potential security situation is avoided by populating the jail system with an pristine copy of the operating system.

It's important to draw your attention to this basic fact about jail systems. The only requirement is the operating system executables contained in the jail system must be at the same level as what the host is running. This is the only way to guarantee the integrity of your production jail system.

Were going to cover both the "make buildworld" method and the "pristine" method  ways of populating the template filesystem with an complete version of the operating system. The instructions covered here is the first step in creating the jail system.

The "make buildworld" method requires the host to have the complete operating system source located at /usr/src. The following commands are going to take some time to compile the source to populate the template filesystem. Once completed you move on to the 16.3.1 Building the Jail System Filesystems section to continue.

     mkdir -p /usr/jail/template
     cd /usr/src
     make world DESTDIR=/usr/jail/template
     make distribution DESTDIR=/usr/jail/template


The "pristine method" uses one of the "RELEASE" compressed install files as source for populating the jail system with an pristine copy of the operating system. Take note: the format of the "RELEASE" compressed install files changed between 8.x and 9.x, the "jail.pristine.fetch" script uses the 9.x format only. Once completed you move on to the 16.3.1 Building the Jail System Filesystems section to continue.


The following script named "jail.pristine.fetch " has been provided. The script has comments which self document what it's doing. Please notice that "/usr/jail" is the location where this script will install the jail system filesystems. You can easily edit this script for any path location you desire, and then also make the same changes to all the other provided scripts shown later.

This script and all the other scripts can be downloaded as a single tar file.
See 16.10 How to download the script tar file for instructions.

To Summarize:
1. Validate pristine method can be used on this host.
2. Do house cleaning so this script can be re-enterable.
3. The base.txz install file is downloaded.
4. The base.txz install file is installed to template.


Instructions for creating this script
touch /usr/local/bin/jail.pristine.fetch
copy and paste the following script text into this file.
chmod 555 /usr/local/bin/jail.pristine.fetch
rehash
Issue this command from the command line jail.pristine.fetch
When it completes the "template filesystem" is created.


********** This is the start of the script **********
#!/bin/sh
# Validate pristine method can be used on this host.
# Get release of running host. (IE: 9.0-RELEASE)
release=`uname -r`

# Strip off the release number from in front of the release name
os_release=${release##*-}

# Remove the security binary patch update version suffix -p3 [if present]
# from os_release. (IE: 9.0-RELEASE-p3)
case ${os_release} in p1|p2|p3|p4|p5|p6|p7|p8|p9|p10|p11|p12|p13) \
# Strip off the word -RELEASE-p3 leaving 9.0
release_number=${release%%-*}
release="${release_number}-RELEASE"
os_release="RELEASE"
;; esac

if [ "${os_release}" != "RELEASE" ]; then
   echo "Host is not running a RELEASE version. ${release}"
   echo "Use the make buildworld method to populate template."
   exit 2
fi

# Strip off -RELEASE word leaving just major release number IE: 9.0
release_number=${release%%-*}

# Replace the . separating 9.0 into 9 0.
release_number=`echo -n "${release_number}" | tr '.' ' '`

# Concatenate into single number.
number=`echo "${release_number}" | awk '{print $1}'`
number=${number}`echo "${release_number}" | awk '{print $2}'`

if [ ${number} -ge 90 ]; then
  installarch=`uname -p`
  installarch="${installarch}/${installarch}"
else
  echo "Error: The Host is running ${release}."
  echo "Must be at 9.0-RELEASE or newer."
  echo "Use the make buildworld method to populate template."
  exit 2
fi

# Prep some variables
download="/usr/jail/download"
template="/usr/jail/template"

# Prep the environment
if [ -d "${download}" ]; then
  rm -r ${download}
  mkdir -p "${download}"
else
  mkdir -p "${download}"
fi

if [ -d "${template}" ]; then
  rm -r ${template}
  mkdir -p "${template}"
else
  mkdir -p "${template}"
fi

# Fetch the online RELEASE install file.
cd "${download}"
ftp ftp2.freebsd.org:pub/FreeBSD/releases/${installarch}/${release}/base.txz

echo " " 
echo "Installing what was downloaded" 
# Install what you downloaded.
xzdec "${download}/base.txz" | tar --unlink -xpJf - -C "${template}"
rm -r "${download}"

# All the schg flaged files end up belonging to sharedfs so they really
# have no effect in the jail system.
# Remove them now so they don't cause problems later.
  chflags -R noschg ${template}
  chflags -R nosunlink ${template}
        
echo "jail.pristine.fetch completed."

********** This is the end of the script **********



16.3.1 Building the Jail System Filesystems

Please NOTE that the jail.pristine.fetch script or the "make buildworld" method from the previous section MUST have been completed before continuing with the script shown here.

To verify you are ready for this step, you can issue "ls -l /usr/jail" and you should see the template filesystem with the date and time that it was created and populated. Issuing "ls -l /usr/jail/template"and you should see what looks like an complete FreeBSD filesystem. If you see all this, then your ready for this step.

The following script named "jail.install.system " has been provided. The script has comments which self document what it's doing. Please notice that "/usr/jail" is the location where this script will install it's jail system filesystem. You can easily edit this script for any path location you desire, and then also make the same changes to all the other provided scripts shown later. Take note; this is the largest script of the whole series.

Upon the completion of running the "jail.install.system" script you will have an Third Generation jail system. Technically when ever the host updates the system source and does a make buildworld, or the "freebsd-update upgrade" command is used to upgrade the host system to a newer RELEASE level, this jail system filesystem  must be rebuilt to match the RELEASE level of the host. This is mandatory for production jail systems that have jail cells accessible from the public internet. The jail.install.system script contains code to remove the sharedfs filesystem when ever it's executed so nothing special has to be done before running this script  to re-build the jail system over an existing jail system.

This script and all the other scripts can be downloaded as a single tar file.
See 16.10 How to download the script tar file for instructions.

To Summarize:
1. It starts by doing house cleaning so this script can be re-enterable.
2. The operating system executables are moved to sharedfs, and links are created.
3. Some necessary directories are added.
4. Delete some un-needed stuff to make template smaller.
5. Populate the template with files from the host for public network access.


Instructions for creating this script
touch /usr/local/bin/jail.install.system
copy and paste the following script text into this file.
chmod 555 /usr/local/bin/jail.install.system
rehash
Issue this command from the command line jail.install.system
When it completes the "jail system filesystems" are created.


********** This is the start of the script **********
#!/bin/sh
# Has template been created?
template="/usr/jail/template"
if [ ! -d "${template}" ]; then
  echo "${template} is not found."
  echo "Run jail.pristine.fetch or perform make buildworld process first"
  echo "to populate ${template}" 
  exit 2
fi

# Prep some varriables
sharedfs="/usr/jail/sharedfs"
jail_conf="/usr/local/etc/jail.conf"
jail_fstab="/usr/local/etc/jail.conf.fstab"
rc_conf="/usr/local/etc/jail.rcconf"
rc_fstab="/usr/local/etc/jail.rcconf.fstab"

rcconf="${template}/etc/rc.conf"
makeconf="${template}/etc/make.conf"
motd="${template}/etc/motd"
periodic="${template}/etc/periodic.conf"
sudoers="${template}/etc/sudoers"

# Prep the environment
if [ -d "${jail_fstab}" ]; then
  rm -r ${jail_fstab}
  mkdir -p ${jail_fstab}
else
  mkdir -p ${jail_fstab}
fi

if [ -d "${rc_fstab}" ]; then
  rm -r ${rc_fstab}
  mkdir -p ${rc_fstab}
else
  mkdir -p ${rc_fstab}
fi

if [ -d "${rc_conf}" ]; then
  rm -r ${rc_conf}
  mkdir -p ${rc_conf}
else
  mkdir -p ${rc_conf}
fi

if [ -d "${jail_conf}" ]; then
  rm -r ${jail_conf}
  mkdir -p ${jail_conf}
else
  mkdir -p ${jail_conf}
fi

if [ -d "${sharedfs}" ]; then
  echo "Removing old sharedfs"
  chflags -R noschg ${sharedfs}
  chflags -R nosunlink ${sharedfs}
  rm -r ${sharedfs}
  mkdir -p ${sharedfs}
else
  mkdir -p ${sharedfs}
fi

# Build list of libraries to move.
dirlist="bin lib libexec sbin sys usr/bin usr/include usr/lib "
dirlist="${dirlist}usr/libdata usr/libexec usr/sbin "
dirlist="${dirlist}usr/src usr/share "

# amd64 needs a extra lib.
case `uname -p` in amd64) dirlist="${dirlist} usr/lib32";; esac

# Copy the selected libraries to sharedfs and delete them from template
# while also creating the links for those libraries.
echo "Building sharedfs"
cd "${template}"
for dir in ${dirlist}; do
  find ${dir} | cpio -dmp "${sharedfs}" 1> /dev/null 2>&1
  chflags -R noschg ${dir}
  chflags -R nosunlink ${dir}
  rm -r ${dir}
  ln -s /sharedfs/${dir} ${dir}
done

# Add these additional directories.
mkdir -p "${template}/usr/ports"
mkdir ${template}/sharedfs
ln -s usr/home ${template}/home

# Delete some un-needed stuff to make template smaller.
rm -rf ${template}/boot
rm -rf ${template}/rescue
rm -rf ${template}/usr/games

# Populate the template with files from the host
# necessary for a network accessible jail.
cp /etc/localtime "${template}/etc/"
cp /etc/resolv.conf "${template}/etc/"

# The ugly perl hack that has been around for ever.
ln -s /usr/local/bin/perl "${sharedfs}/usr/bin/perl"

echo "Configuring template"
# Populate some jail configuration files for running as a jail.
#
echo "# No network interfaces in jails" > "${rcconf}"
echo "network_interfaces=\"\"" >> "${rcconf}"
echo " " >> "${rcconf}"
echo "# Prevent rpc" >> "${rcconf}"
echo "rpcbind_enable=\"NO\"" >> "${rcconf}"
echo " " >> "${rcconf}"
echo "# Prevent jails from doing their cron jobs at the same time" >> "${rcconf}"
echo "cron_flags=\"$cron_flags -J 60\"" >> "${rcconf}"
echo " " >> "${rcconf}"
echo "# Prevent syslog from opening sockets" >> "${rcconf}"
echo "syslogd_flags=\"-ss\"" >> "${rcconf}"
echo " " >> "${rcconf}"
echo "# Prevent sendmail from trying to connect to localhost" >> "${rcconf}"
echo "sendmail_enable=\"NO\"" >> "${rcconf}"
echo "sendmail_submit_enable=\"NO\"" >> "${rcconf}"
echo "sendmail_outbound_enable=\"NO\"" >> "${rcconf}"
echo "sendmail_msp_queue_enable=\"NO\"" >> "${rcconf}"

echo "WRKDIRPREFIX=   /var/ports" > "${makeconf}"
echo "DISTDIR=        /var/ports/distfiles" >> "${makeconf}"
echo "PACKAGES=       /var/ports/packages" >> "${makeconf}"
echo "INDEXDIR=       /var/ports" >> "${makeconf}"

echo "Welcome to your FreeBSD jail." > "${motd}"

echo "daily_output=\"/var/log/daily.log\"" > "${periodic}"
echo "weekly_output=\"/var/log/weekly.log\"" >> "${periodic}"
echo "monthly_output=\"/var/log/monthly.log\"" >> "${periodic}"
echo "daily_status_security_output=\"/var/log/daily_status_security.log\"" >> "${periodic}"
echo "daily_status_network_enable=\"NO\"" >> "${periodic}"
echo "daily_status_security_ipfwlimit_enable=\"NO\"" >> "${periodic}"
echo "daily_status_security_ipfwdenied_enable=\"NO\"" >> "${periodic}"
echo "weekly_whatis_enable=\"NO\"" >> "${periodic}"

echo "root    ALL=(ALL) ALL" > "${sudoers}"
echo "%wheel  ALL=(ALL) ALL" >> "${sudoers}"

echo "jail.install.system completed."

********** This is the end of the script **********



16.3.2 Creating & Deleting Jail Cell Filesystems

No matter which jail cell definition method you chose to use, "legacy rc.d method" or "modern rc.d method" or "jail.conf method" they all have one thing in common, each individual jail cell needs it's own physical filesystem to run in. The creating and deleting of individual jail cell filesystems is an separate function from the creating and deleting of individual jail cell definition statement files based on one of the three definition methods.

The following two scripts named "jail.create.jailcell" and "jail.delete.jailcell" have been provided. These scripts have comments which self document what it's doing. Please notice that "/usr/jail" is the location where these scripts will create and delete the individual jail cell filesystems. You can easily edit the script for any path location you desire, but for uniformity it should be the same location the jail system is installed at.

This script and all the other scripts can be downloaded as a single tar file.
See 16.10 How to download the script tar file for instructions.

The "jail.create.jailcell" script requires a single parameter to function. It needs a "jail cell name". Issued from the console command line it would look something like this   jail.create.jailcell dir0   where dir0 is the jail cell name.

There is a jail cell naming standard which is designed to alleviate technical problems when trying to start jail cells. Only underscore, dash and alphanumeric characters are valid in the jail cell name, and jail cell names that are all numeric are invalid.

It's up to the user to keep manual records of what jail cell names have already been assigned.

To Summarize the jail.create.jailcell script:
  1. It starts by checking if the required parameter is included.
  2. Prep some variables.
  3. Inspect the entered jail cell name.
  4. Check to see if jail cell name is used already.
  5. Create the new jail cell named filesystem by coping the contents of the template to it.
Instructions for creating this script
touch /usr/local/bin/jail.create.jailcell
copy and paste the following script text into this file.
chmod 555 /usr/local/bin/jail.create.jailcell
rehash


********** This is the start of the script **********
#!/bin/sh
# Did you pass the required parameter to this script like this.
# jail.create.jailcell jailcellname

if [ $# -lt 1 ]; then
  echo "The required jail cell name parameter is missing."
  exit 2
fi

# Prep some variables
rootdir="/usr/jail/$1"
template="/usr/jail/template"

# Inspect the entered jail cell name.
safename=`echo -n "$1" | tr -c '[:alnum:]-_' _`
if [ "${safename}" != "$1" ]; then
   echo "Invalid jail cell name"
   echo "Only underscore, dash and alphanumeric characters are valid."
   exit 2
fi

# Check that the jail name is not all numeric.
if expr "$1" : "[0-9]*$" > /dev/null
    then
     echo "All numeric jail names are invalid. Jail name $1"
     exit 2  
fi

# Check to see if jail cell name is used already.
if [ -d "${rootdir}" ]; then
   echo "Jail cell name is already used $1"
   exit 2
fi
 
# Create the jail cell name filesystem.
mkdir -p "${rootdir}"
cd "${template}"
find . | cpio -p "${rootdir}" 1> /dev/null 2>&1
if [ $? -ne 0 ]; then
  echo "Error: Couldn't copy template."
  exit 2
fi

echo "jail.create.jailcell completed for $1"

********** This is the end of the script **********


jail.delete.jailcell script:
This will delete the jail cell's physical filesystem. This script requires a single parameters to function. It needs the jail cell name to delete.

To Summarize the jail.delete.jailcell script:
  1. It starts by checking if the single required parameter is included.
  2. Prep some variables.
  3. Check if definition file has been deleted already.
  4. Check if jail is running.
  5. Check to see if jail name exists and if so delete all of the jail cell files.
Instructions for creating this script
touch /usr/local/bin/jail.delete.jailname
copy and paste the following script text into this file.
chmod 555 /usr/local/bin/jail.delete.jailcell
rehash


********** This is the start of the script **********
#!/bin/sh
# Did you pass the required parameters to this script like this.
# jail.delete.jailcell jailcellname

if [ $# -lt 1 ]; then
  echo "The required jail cell name parameter is missing."
  exit 2
fi

# Prep some varriables
rootdir="/usr/jail/$1"
jail_conf="/usr/local/etc/jail.conf/$1"
rc_conf="/usr/local/etc/jail.rcconf/$1"

# Check if jail is running.
jail_list=`jls name`
for jail in ${jail_list}; do
  if [ "${jail}" = "$1" ]; then
    echo "Can not delete a running jail cell"
    exit 2
  fi
done

# Check if definition file has been deleted already.
if [ -e "${jail_conf}" -o -e "${rc_conf}" ]; then
   echo "The jail cell definition must be deleted before"
   echo "the jail cell filesystem can be deleted."
   exit 2
fi
 
if [ -d "${rootdir}" ]; then
  chflags -R noschg ${rootdir}
  chflags -R nosunlink ${rootdir}
  rm -r ${rootdir}
  echo "jail.delete.jailcell completed for $1"
else
  echo "jail cell name not found $1"
fi

********** This is the end of the script **********



16.3.3 Enabling Jail Cell SSH Support

The jail cell's filesystem has to be updated to enable SSH support. The "jail.ssh.jailcell" script does this function. On the first start of that jail cell after running this script, SSH will be enabled from that point on. After this jail cell is started you have to create user accounts in that jail cell for users to login to.

To create user accounts in the jail cell you will have to open a jail cell root session using the host's "jexec" command and create the new user accounts you want using the pw command. Then restart the jail cell and you will be able to do SSH logins using the jail cell's IP address.

You would code this command on the host's command line this way      jexec jailcellname tcsh
Once your talking to the jail cell, you have all the normal abilities you would expect as a root user on the host. Entering exit will close down your session with the jail cell.

       pw adduser login.name -p 12-12-12 -c jail user -m -g wheel -w yes
This format of the pw command will assign the login password to be the same as the login.name and the -p flag will force the user to change that password on first login.

jail.ssh.jailcell  script:
This script requires a single parameter to function. It needs the jail cell name you want to target.
This script and all the other scripts can be downloaded as a single tar file.
See 16.10 How to download the script tar file for instructions.

Instructions for creating this script
touch /usr/local/bin/jail.ssh.jailcell
copy and paste the following script text into this file.
chmod 555 /usr/local/bin/jail.ssh.jailcell
rehash


********** This is the start of the script **********
#!/bin/sh
# Did you pass the required parameters to this script like this.
# jail.ssh.jailcellname jailcellname

if [ $# -lt 1 ]; then
  echo "The required jail cell name parameter is missing"
  exit 2
fi

# Prep variables
rootdir="/usr/jail/$1"
rcconf="${rootdir}/etc/rc.conf"
sshdns="${rootdir}/etc/ssh/sshd_config"

# Check to see if jail cell name is there.
if [ ! -d "${rootdir}" ]; then
   echo "No Jail cell found by that name $1"
   exit 2
fi

# Populate the jails rc.conf for ssh.
echo "sshd_enable=\"YES\"" > "${rcconf}"

# Turn off reverse dns lookup so no waiting for
# time out during ssh start up.
echo "UseDNS no" > "${sshdns}"

echo "jail.ssh.jailcell completed for $1"

********** This is the end of the script **********



16.4 The jail.conf Method

The jail.conf method became available to the general public with the publication of the 9.1-RELEASE. It defaults to using the /etc/jail.conf file as the depository of all the jail cell definition statements under it's control. This is not a mandatory requirement. Jail cell definition statements can also be separated into individual files for easy control of starting / stopping individual jail cells. That is how the jail cell definition statements are organized and utilized by the provided scripts. The /usr/sbin/jail program provides the start / stop control of jail cells defined utilizing the jail.conf definition syntax. The syntax provides for enabling parameters on a per jail cell basis.

After reading this section, you will:

During the development of the jail.conf file method documented here, a few bugs came to light with the jail(8) program which the author has fixed, but which are not included in the 9.1-RELEASE. You can wait for the publishing of 9.2-RELEASE which will contain the updated version of jail(8) or you can download just the source for jail(8) and compile it to use on your 9.1-RELEASE system.

If this is too close to the bleeding edge for you or if your jail system is intended for production security of public accessible processes, then I recommend you use the modern rc.d method for your jail cell definition as documented here 16.5 The Modern rc.d Method.

First you have to install the the "subversion port", then you can use the provided "jail.svn.src.jail8" script to download the jail program source. Then perform "make" on it. After that completes move the executable to /usr/sbin/jail and give the file execution permission (chmod 555 /usr/sbin/jail).

This script and all the other scripts can be downloaded as a single tar file.
See 16.10 How to download the script tar file for instructions.

Instructions for creating this script
touch /usr/local/bin/jail.svn.src.jail8
copy and paste the following script text into this file.
chmod 555 /usr/local/bin/jail.svn.src.jail8
rehash
jail.svn.src.jail8
cd /usr/src/usr.sbin/jail
make
mv /usr/sbin/jail /usr/sbin/jail.org
cp jail /usr/sbin/
chmod 555 /usr/sbin/jail


********** This is the start of the script **********
#!/bin/sh

url="svn://svn.freebsd.org/base/head"

srcname="/usr.sbin/jail"

svn checkout $url/$srcname /usr/src/$srcname

********** This is the end of the script **********



16.4.1 jail.conf Definition Statements

This is the jail.conf  jail definition statements created by the jail.jailconf.def.create script. It's contains the definition parameters necessary for a standard jail. The syntax has some requirements which are similar to defining a function in a "sh" script. Notice the position of the opening and closing { }curly bracket. Values for the parameter must be enclosed in quotes "  " and terminated with a ; semicolon.

dir00 {
host.hostname  = "dir00";
ip4.addr           = "10.0.10.30";
interface           = "rl0"
path                  = "/usr/jail/dir00";
mount.fstab      = "/usr/local/etc/jail.conf.fstab/dir00 ";
exec.start         = "/bin/sh /etc/rc";
exec.stop         = "/bin/sh /etc/rc.shutdown";
exec.consolelog = "/var/log/jail.dir00.console.log";
mount.devfs;
}


dir00   Is the jail cell name and is inserted in 5 different jail cell definition parameters. Substitute your jail cell name for dir00.

host.hostname    This is the jail cell name. It becomes the value for the hostname command visible only from within the running jail cell. It has nothing to do with DNS access to the jail cell and does not have to be a fully qualified domain name like on the host system.

ip4.addr   This is the IP4 address / addresses to be assigned to the jail cell. The jail cell's primary IP address is used to access the jail over the network. Multiple IP addresses are allowed if each IP address in the list is separated by a "," comma. If multiple IP addresses are coded this parameter can not be enclosed in quotes.

interface   This is the NIC device name which to attach the IP address / addresses to. An alias will be automatically created on jail cell start and automatically removed on jail cell stop.

path   This is the path to the jail cell's filesystem mount point.

mount.fstab   This is the path to the file containing the fstab format type of record defining the mounting of the shared sharedfs as an read only nullfs filesystem. This path /usr/local/etc/jail.conf.fstab/ is the location used by the provided scripts, do not change it.

exec.start   This is the normal script used to start the jail cell.

exec.stop   This is the normal script used to stop the jail cell.

exec.consolelog   This creates the jail cells console log on first jail cell start and appends all following jail cell console messages to the bottom of this file.

mount.devfs   This enables the ability for the jail to auto mount the dev file system and apply rule number 4 as the default which restricts the devices visible inside the running jail cell..



There are many jail(8) parameters available, most are special purpose for the advanced user. But there are some which the general user may find interesting. They are listed here;

ip6.addr = ip6 address /addresses to be assigned to the jail cell. It's the counterpart to ip4.addr.

securelevel = -1, 0, 1, 2, 3 values as defined in "man security". This does not really apply to the third generation jail system described here because all of the system executables are in an read only nullfs mounted filesystem which makes them impossible from being changed. The third generation jail system is by far a stronger form of jail security than the securelevel parameter can provide on an per-jail basis.

allow.mount.nullfs on a per-jail basis. This is restricted to directories inside of the jail. It has nothing to do with mounting nullfs from the host to the jail filesystem which is always available to do. Any mount_nullfs commands issued from within the jail are only in effect for the duration the jail cell is running. When the jail cell is stopped the established nullfs mount is neutralized. The exec.prestart or exec.poststart parameters may be used to automate the issuing the desired mount_nullfs commands.

allow.mount.zfs on a per-jail basis. This parameter has mandatory host requirements before it's useful. The host must have all or some part of it's hard drive space defined to zfs and actively using it. See zfs(8) for information on how to configure the zfs filesystem to operate from inside a jail. The exec.prestart or exec.poststart parameters may be used to automate the issuing of the desired zfs commands.

allow.quotas on a per-jail cell basis. This parameter has mandatory host requirements before it's useful. The host  must have quota compiled into it's kernel before this parameter has any effect on the started jail cell.

allow.sysvipc on a per-jail basis. This parameter breaks the security of the jail concept. It should never by enabled on a jail cell exposed to the public internet. This allows a process within a jail cell access to the System V IPC primitives. In the current jail(8) implementation, System V IPC primitives share a single namespace across the host and all jail(8) environments, meaning that processes within a jail cell would be able to communicate with (and potentially interfere with) processes outside of the jail cell, (the host and other jail cells).

devfs_ruleset on a per-jail basis. If for what ever reason you would need to have a special rule, you would add it to /etc/defaults/devfs.rules and code this parameter like this devfs_ruleset = "7" to assign that rule number to this jail cell only. See devfs(8) for more details.

allow.raw_sockets on a per-jail basis. This parameter breaks the security of the jail concept. It should never by enabled on a jail exposed to the public internet. Normally the ping command will get "Operation not permitted." error when issued from inside of a jail cell. This is a security feature embedded in the basic design of the FreeBSD jail environment. This default does not allow users or jail cell applications to create raw sockets. With raw sockets enabled, a jail cell user could use perl or python or some other port utility to create raw sockets and launch attacks on the host or the public network. If the jail cell has public internet access, an public attacker may compromise the jail cell and launch attacks on the host or the public network. The whois or dig commands can be used for the same purpose of determining if the jail cell has public internet access. Consideration of the security risk verses the convenience of using the ping command from inside the jail is of the highest order.

vnet on a per-jail basis. This parameter requires the experimental vimage to be compiled into the hosts kernel before enabling this parameter. If vimage is not compiled into the host's kernel and this parameter is included in the jail cells definition, it will cause the starting of the jail to fail with "unknown parameter vnet".

vnet.interface  This is the companion with the vnet parameter. Required when vnet parameter is coded. You populate it with the NIC device name of the interface you want vnet to use.

exec.fib on a per-jail cell basis. This parameter is used only under very special conditions by technically advanced users. It deals with alternate routing tables. It requires either a new kernel (with "options ROUTETABLES=2" or however many you want), or a boot-time setting with "net.fibs=2" in /boot/loader.conf (requiring a reboot).
setfib 1 route add default 198.192.64.21 creates routing table number 1 with that IP address. In this example exec.fib="1" would be coded. See setfib(8) and setfib(2) for details.

cpuset.id on a per-jail basis. This parameter is used to limit the number of CPUs the jail cell may use of the total CPUs available on the machine. Issuing "cpuset -g" command on the host will list the CPU identification number of each CPU available. Assigning a jail cell to an single CPU does not give that jail cell exclusive usage of the CPU or does it exclude other host processes from using that CPU. If  the "cpuset -g" command listed 0, 1, 2, 3, 4, 5, 6, 7 that means this computer has 8 CPU's. Coding cpuset.id=0,1,2 means CPU 0, 1, and 2 out of the 8 available CPUs are being assigned to this jail restricting that jail from using CPUs 3, 4, 5, 6, and 7.

 See rctl(8) for true resource control. Also this wiki article does a good job explaining what rctl does and how it works. https://wiki.freebsd.org/Hierarchical_Resource_Limits .



16.4.2 Creating & Deleting the jail.conf jail cell Definition File

The following two scripts named "jail.jailconf.def.create" and  "jail.jailconf.def.delete" have been provided. These scripts have comments which self document what it's doing. Please notice that "/usr/jail" is the location where these scripts will create and delete the individual jail cells. You can easily edit the script for any path location you desire, but for uniformity if should be that same location the jail system is installed at.

This script and all the other scripts can be downloaded as a single tar file.
See 16.10 How to download the script tar file for instructions.

The "jail.jailconf.def.create" script requires 2 parameters to function and has 1 optional parameter. It needs a jailcellname, ip-address, and in most cases the NIC device name that ip-address is to be aliased to. Issued from the console command line it would look something like this jail.jailconf.def.create dir0 10.0.10.20 rl0

It's up to the user to keep manual records of what ip-address have already been assigned so no 2 jail cells have the same ip-address. It's also up to the user to keep manual records of what jail cell names have already been assigned.

The "jail.jailconf.def.create" script checks for the existence of a jail cell filesystem having the jail cell name entered with this script at execution. The jail.create.jailcel script must be run before this script to create the jail cell filesystem first.

To Summarize the jail.jailconf.def.create script:

  1. Checking if the three required parameters are included.
  2. Prep some variables.
  3. Check to see if jail cell name has a filesystem.
  4. Check to see if jail cell name has definition already.
  5. Create the fstab file for jail cell name, it's used at boot time and jail cell start time to mount the sharedfs as a read only nullfs filesystem mounted to each individual jail cell. Note that all fstab files are grouped together at path /usr/local/etc/jail.fstab/ with a file name of the jailcellname.
  6. Create the jail.conf file and populate the jail.conf parameters with the values from the three required parameters entered with the jail.jailconf.def.create script. Note that all jail.conf files are grouped together at path /usr/local/etc/jail.conf/ with a file name of the jailcellname.
Instructions for creating this script
touch /usr/local/bin/jail.jailconf.def.create
copy and paste the following script text into this file.
chmod 555 /usr/local/bin/jail.jailconf.def.create
rehash


********** This is the start of the script **********
#!/bin/sh
# Did you pass the required parameters to this script like this.
# jail.def.create.jailconf jailcellname ip_address NIC_name

if [ $# -lt 2 ]; then
  echo " "
  echo "The required 2 parameters are missing"
  echo "First parameter is jail cell name"
  echo "Second parameter is the IP address assigned to this jail cell"
  echo "Third parameter is the NIC device name the"
  echo "IP address is associated with. It's optional."
  exit 2
fi

# Prep some variables
rootdir="/usr/jail/$1"
template="/usr/jail/template"
sharedfs="/usr/jail/sharedfs"
jail_conf="/usr/local/etc/jail.conf/$1"
jail_fstab="/usr/local/etc/jail.conf.fstab/$1"

# Check to see if jail cell name has filesystem.
if [ ! -d "${rootdir}" ]; then
   echo "Jail cell name does not have a filesystem $1"
   exit 2
fi

# Check to see if jail cell name has definition already.
if [ -e "${jail_conf}" ]; then
   echo "Jail cell name has a definition already $1"
   exit 2
fi

# Create the fstab file for the new jailname,
# it is used at boot time and jail start/stop time,
# to mount/unmount the sharedfs as a read only nullfs filesystem.
#
echo ${sharedfs} ${rootdir}/sharedfs nullfs ro 0 0 > "${jail_fstab}"

# Create the jail.conf file for this jail.
echo -n > "${jail_conf}"
echo "$1 {" >> "${jail_conf}"
echo "host.hostname       =  \"$1\";" >> "${jail_conf}"
echo "ip4.addr            =  \"$2\";" >> "${jail_conf}"
echo "path                 =  \"${rootdir}\";" >> "${jail_conf}"
echo "mount.fstab         =  \" ${jail_fstab}\";" >> "${jail_conf}"
echo "exec.start          =  \" /bin/sh /etc/rc\";" >> "${jail_conf}"
echo "exec.stop           =  \" /bin/sh /etc/rc.shutdown\";" >> "${jail_conf}"
echo "exec.consolelog     =  \"/var/log/jail.$1.console.log\ ";" >> "${jail_conf}"
[ $3 ] && \
echo "interface           =  \" $3\";" >> "${jail_conf}"
echo "mount.devfs;" >> "${jail_conf}"
echo "}" >> "${jail_conf}"

echo "jail.jailconf.def.create completed for $1"

********** This is the end of the script ***********


jail.jailconf.def.delete script:
This script requires a single parameters to function. It needs the jail cell name to delete. Use "ls /usr/local/etc/jail.conf to list all your jail cell names. After this script completes you need to run "jail.delete.jailcell " script to delete the jail cell's filesystem.

To Summarize the jail.jailconf.def.delete script:
  1. Check if the single required parameter is included.
  2. Prep some variables.
  3. Check to see if definition is really there.
  4. Check if jail cell is running.
  5. Delete the fstab file.
  6. Delete the definition file.
Instructions for creating this script.
touch /usr/local/bin/jail.jailconf.def.delete
copy and paste the following script text into this file.
chmod 555 /usr/local/bin/jail.jailconf.def.delete
rehash


********** This is the start of the script **********
#!/bin/sh
# Did you pass the required parameters to this script like this.
# jail.jailconf.def.delete jailcellname

if [ $# -lt 1 ]; then
  echo " "
  echo "The required jail cell name parameter is missing."
  exit 2
fi

# Prep some variables
jail_fstab="/usr/local/etc/jail.conf.fstab/$1"
jail_conf="/usr/local/etc/jail.conf/$1"
console_log="/var/log/jail.$1.console.log"

# Check to see if its really there.
if [ ! -e "${jail_conf}" ]; then
   echo "This jail cell name does not exist $1"
   exit 2
fi

# Check if jail cell is running.
jail_list=`jls name`
for jail in ${jail_list}; do
  if [ "${jail}" = "$1" ]; then
    echo "Can not delete a definition file of a running jail cell"
    exit 2
  fi
done

# Delete the fstab file.
 rm "${jail_fstab}"

# Delete the definition file.
rm "${jail_conf}"

# Delete the console log file.
rm "${console_log}"

echo "jail.jailconf.def.delete completed for $1"

********** This is the end of the script ************



16.4.3 Starting & Stopping jail.conf jail cells

The following two scripts named "jail.jailconf.start" and "jail.jailconf.stop" have been provided. These scripts have comments which self document what it's doing.

This script and all the other scripts can be downloaded as a single tar file.
See 16.10 How to download the script tar file for instructions.

jail.jailconf.start script:
This script requires a single parameter to function. It needs the jailcellname of the jail cell you want started.

Instructions for creating this script.
touch /usr/local/bin/jail.jailconf.start
copy and paste the following script text into this file.
chmod 555 /usr/local/bin/jail.jailconf.start
rehash


********** This is the start of the script **********
#!/bin/sh
# Did you pass the required parameters to this script like this.
# jail.jailconf.start jailcellname

if [ $# -lt 1 ]; then
  echo "Error: The required jail cell name parameter is missing."
  exit 2
fi

jail_conf="/usr/local/etc/jail.conf/$1"
if [ ! -e "${jail_conf}" ]; then
   echo "Invalid jail cell name. It does not exist."
   exit 2
fi

# Issue command to start the jail
/usr/sbin/jail -q -f "${jail_conf}" -c
if [ $? -ne 0 ]; then
  echo "Error: /usr/sbin/jail failed to start jail $1."
  echo "because of errors in jail.conf file."
  exit 2
else
  echo "jail.jailconf.start completed for $1"
fi

********** This is the end of the script **********


jail.jailconf.stop script:
This script requires a single parameter to function. It needs the jailcellname of the jail cell you want stopped.

Instructions for creating this script.
touch /usr/local/bin/jail.jailconf.stop
copy and paste the following script text into this file.
chmod 555 /usr/local/bin/jail.jailconf.stop
rehash


********** This is the start of the script **********
#!/bin/sh
# Did you pass the required parameters to this script like this.
# jail.jailconf.stop jailcellname

if [ $# -lt 1 ]; then
  echo "Error: The required jail cell name parameter is missing."
  exit 2
fi

jail_conf="/usr/local/etc/jail.conf/$1"
if [ ! -e "${jail_conf}" ]; then
   echo "Invalid jail cell name. It does not exist."
   exit 2
fi

# Issue the command to stop the jail
/usr/sbin/jail -q -f "${jail_conf}" -r $1
if [ $? -ne 0 ]; then
  echo "Error: /usr/sbin/jail failed to stop jail $1."
  echo "because of errors in jail.conf file."
  exit 2
else
  echo "jail.jailconf.stop completed for $1"
fi

********** This is the end of the script ************



16.4.4 Boot Starting & Shutdown Stopping of jail.conf jail cells

The following script named "jail.jailconf.bootime" has been provided. This script has comments which self document what it's doing.

This script and all the other scripts can be downloaded as a single tar file.
See 16.10 How to download the script tar file for instructions.

This is a rc.d-method type script because the rc.d system is the only way to implement boot time access to the jail system. To enable boot time start up of all the jail system's jail.conf type of jail cells, the host's /etc/rc.conf file needs this statement added, jailconf_enable="YES" and the jail.jailconf.bootime file has to be in the hosts /usr/local/etc/rc.d directory with read/execute file permissions.

Note: For orderly stopping of the jailconf jail cells the host system must issue the "shutdown now" command. Using the reboot or halt commands just terminates the running jail cells. This may damage data bases running inside the jail cells.

Instructions for creating this script.
touch /usr/local/etc/rc.d/jail.jailconf.bootime
copy and paste the following script text into this file.
chmod 555 /usr/local/etc/rc.d/jail.jailconf.bootime
rehash


********** This is the start of the script **********
#!/bin/sh
# This script exclusively uses the /etc/jail.conf file method instead
# of the rc.d-method for starting jails.
#
# If jailconf_enable="YES" is coded in /etc/rc.conf, then this script
# will execute at boot time and shutdown time.
# This file must have execute permission "chmod 555 jail.jailconf.bootime"
# to work.
#
# The jail_stop routine will only get executed if the host
# issues the "shutdown now" command.
# Using the reboot & halt commands just terminates all jails.
# This may damage data bases running inside of jails.

# PROVIDE: jailconf
# REQUIRE: LOGIN cleanvar
# BEFORE: securelevel
# KEYWORD: nojail shutdown

. /etc/rc.subr

name=jailconf
rcvar=`set_rcvar`
load_rc_config ${name}

jailconf_enable=${jailconf_enable:-"NO"}

start_cmd="jail_start"
stop_cmd="jail_stop"

jail_start()
{
  # Start all jails.

  jail_conf="/usr/local/etc/jail.conf"

  if [ -d "${jail_conf}" ]; then
    cd "${jail_conf}"
    jail_list=`ls`
  else
    echo "${jail_conf} not found"
    exit 2
  fi   

  for jail in ${jail_list}; do
    jail_pid="/var/run/jailconf.${jail}.pid"
    /usr/sbin/jail -i -f "${jail_conf}/${jail}" -c >" ${jail_pid}"
    chmod 555 "${jail_pid}"
    if [ $? -ne 0 ]; then
      echo "Error: /usr/sbin/jail failed to start jail cell ${jail}"
      echo "because of errors in file ${jail_conf}/${jail}"
      exit 2
    else
      echo "jail.conf jail cell successfully started  ${jail} "
  done
}


jail_stop()
{

  # Only stop jails that are currently running and belong to jail_conf.
  # Using the "jls" command to build list of jail names that are running.
              
  jail_list=`jls name`

  for jail in ${jail_list}; do
    jail_conf="/usr/local/etc/jail.conf/${jail}"
    [ -e "${jail_conf}" ] || continue

    /usr/sbin/jail -q -f "${jail_conf}" -r "${jail}"
    jail_pid="/var/run/jailconf.${jail}.pid"
    rm "${jail_pid}"
        
    if [ $? -ne 0 ]; then
      echo "Error: /usr/sbin/jail failed to stop jail cell ${jail_conf}"
      echo "because of errors in jail.conf file."
      exit 2
    else           
      echo "jail.conf jail cell successfully stopped ${jail}"
    fi
  done
  }

run_rc_command $*

********** This is the end of the script ***********



16.5 The Modern rc.d Method

Since FreeBSD 4.0 when the /etc/rc.d/jail script first became available, all jail cells were based on jail cell definition statements being placed in the host's /etc/rc.conf file and the start / stop control accomplished using /etc/rc.d scripts launched by the "service jail" command. In this document this is now called the legacy rc.d method. What is documented here will work with all RELEASEs back to 4.0-RELEASE.

The modern rc.d method explained here has divorced it self from relying on the "service jail" command for starting and stopping jail cells and no longer do the rc.conf jail cell definition statements have to reside in the host's /etc/rc.conf file. They can now reside anywhere on the host's filesystem. This is basically the same freedom the jail.conf file method provides.

The modern rc.d method has been available since FreeBSD 4.0, but due to the complexity of the rc.d environment and how the /etc/rc.d/jail script was implemented, only a few people had the knowledge and/or the understanding to make the rc.d jail environment more flexible and user friendly. This method has never been documented before and is presented here as an alternative to the current legacy rc.d method.

The modern rc.d method uses the third generation jail system which has been designed with two directories for grouping the fstab records and the rc.conf type of definition statements into individual files. Only the organization of the location for storing the files has changed, plus the direct execution of the /etc/rc.d/jail script. The deployment of this modern rc.d method is simple and easy. Current legacy rc.d method jail users will feel right at home using the modern rc.d method.

After reading this section, you will:


16.5.1 rc.conf Definition Statements

The following group of rc.conf jail cell definition statements are what is required for a standard jail cell.
This is the rc.conf jail definition statements created by the jail.rcconf.def.create script. It's contains the definition parameters necessary for a standard jail. The syntax has a single requirement, the values for the parameters must be enclosed in quotes " ".


jail_rc-dir0_hostname="rc-dir0"
jail_rc-dir0_rootdir="/usr/jail/rc-dir0"
jail_rc-dir0_fstab="/usr/local/etc/jail.rcconf.fstab/rc-dir0"
jail_rc-dir0_ip="10.0.10.20"   
jail_rc-dir0_interface="rl0"
jail_rc-dir0_mount_enable="YES"
jail_rc-dir0_devfs_enable="YES"
jail_rc-dir0_flags="-n rc-dir0 -l -U root"
jail_rc-dir0_exec_start="/bin/sh /etc/rc"
jail_rc-dir0_exec_stop="/bin/sh /etc/rc.shutdown"


rc-dir0 This is the jail cell name. It gets inserted 14 times into the standard rc.conf definition statements. Substitute your jail cell name for rc-dir00.

jail_rc-dir0_hostname  This is the jail cell name. It becomes the value for the hostname command visible only from within the running jail cell. It has nothing to do with DNS access to the jail cell.

jail_rc-dir0_rootdir  This is the path of the mount point of the jail cell. It's the top of the jails cells filesystem.

jail_rc-dir0_fstab This is the path to the file containing the fstab format type of record defining the mounting of the shared sharedfs as a read only nullfs filesystem. This path /usr/local/etc/jail.rcconf.fstab/ is the location used by the provided scripts, do not change it. .

jail_rc-dir0_ip Set to the primary IPv4 and/or the IPv6 addresses assigned to the jail cell. May be a sole address or a comma separated list of IP addresses. The jail cell's primary IP address is used to access the jail cell over the network.

jail_rc-dir0_interface   This is the NIC device name of the interface to be used when setting IP address alias. The alias is automatically created on jail cell startup and removed on jail cell stopping.

jail_rc-dir0_mount_enable  This causes the auto mount of all the entries pointed to by the jail_rc-dir0_fstab parameter on jail cell start up and auto dismounted at jail cell stop time.

jail_rc-dir0_devfs_enable  Auto mount the device file system inside the jail cell and defaults to using rule set number 4 which limits what devices a jail cell has access to.

jail_rc-dir0_flags This forces the internal population of the jail cell name variable so the "jls name" command will have the jail cell name to list instead of being forced  to list the JIDs which is unwanted.

jail_rc-dir0_exec_start and jail_rc-dir0_exec_stop  These are the default values. These statements are not required, but it's a good practice to always include them so any one coming along later will know for certain what the jail cell definition consists of.


Other sources of useful information about the rc.conf definition statements are:


16.5.2 Creating & Deleting the rc.conf jail cell Definition file

The following two scripts named "jail.rcconf.def.create" and  "jail.rcconf.def.delete" have been provided. These scripts have comments which self document what it's doing. Please notice that "/usr/jail" is the location where these scripts will create and delete the individual jail cells. You can easily edit the script for any path location you desire, but for uniformity if should be that same location the jail system is installed at.

This script and all the other scripts can be downloaded as a single tar file.
See 16.10 How to download the script tar file for instructions.

The "jail.rcconf.def.create" script requires 2 parameters to function and 1 option parameter. It needs a jailcellname, ip-address, and in most cases the NIC device name that ip-address is to be aliased to. Issued from the console command line it would look something like this jail.rcconf.def.create dir0 10.0.10.20 rl0

It's up to the user to keep manual records of what ip-address have already been assigned so no 2 jail cells have the same ip-address. It's also up to the user to keep manual records of what jail cell names have already been assigned.

The "jail.rcconf.def.create" script checks for the existence of a jail cell filesystem having the jail cell name entered with this script at execution. The jail.create.jailcel script must be run before this script to create the jail cell filesystem first.
To Summarize the jail.rcconf.def.create script:
  1. Check if the three required parameters are included.
  2. Prep some variables.
  3. Check to see if jail cell name has filesystem.
  4. Check to see if jail cell name has definition file already.
  5. Create the jailcellname directory and copy the contents of the template to it.
  6. Create the fstab file for the new jail cell name, it's used at boot time and jail cell start time to mount the sharedfs as a read only nullfs filesystem mounted to each individual jail cell. Note that all fstab files are grouped together at path /usr/local/etc/jail.rcconf.fstab/ with a file name of the jail cell name.
  7. Create the rc.conf file and populate the rc.conf parameters with the values from the three required parameters entered with the jail.rcconf.def.create script. Note that all rc.conf files are grouped together at path /usr/local/etc/jail.rcconf/ with a file name of the jailcellname.

Instructions for creating this script.
touch /usr/local/bin/jail.rcconf.def.create
copy and paste the following script text into this file.
chmod 555 /usr/local/bin/jail.rcconf.def.create
rehash


********** This is the start of the script **********
#!/bin/sh
# Did you pass the required parameters to this script like this.
# jail.rcconf.def.create jailcellname ip_address NIC_name

if [ $# -lt 2 ]; then
  echo " "
  echo "The required 2 parameters are missing"
  echo "First parameter is jail cell name"
  echo "Second parameter is the IP address assigned to this jail cell"
  echo "Third parameter is the NIC device name the"
  echo "IP address is associated with. It's optional."
  exit 2
fi

# Prep some variables
rootdir="/usr/jail/$1"
sharedfs="/usr/jail/sharedfs"
rc_conf="/usr/local/etc/jail.rcconf/$1"
rc_fstab="/usr/local/etc/jail.rcconf.fstab/$1"

# Check to see if jail cell name has filesystem.
if [ ! -d "${rootdir}" ]; then
   echo "Jail cell name does not have a filesystem $1"
   exit 2
fi

# Check to see if jail cell name has definition already.
if [ -e "${rc_conf}" ]; then
   echo "Jail cell name has a definition already $1"
   exit 2
fi

# Create the fstab file for the new jailname,
# it is used at boot time and jail start/stop time,
# to mount/unmount the sharedfs as a read only nullfs filesystem.
#
echo ${sharedfs} ${rootdir}/sharedfs nullfs ro 0 0 > "${rc_fstab}"

# Create the rc.conf file for this jail.
echo "export jail_$1_hostname=\"$1\"" > "${rc_conf}"
echo "export jail_$1_rootdir=\"$rootdir\"" >> "${rc_conf}"
echo "export jail_$1_fstab=\"$rc_fstab\"" >> "${rc_conf}"
echo "export jail_$1_ip=\"$2\"" >> "${rc_conf}"
[ $3 ] && \
echo "export jail_$1_interface=\"$3\"" >> "${rc_conf}"
echo "export jail_$1_mount_enable=\"YES\"" >> "${rc_conf}"
echo "export jail_$1_devfs_enable=\"YES\"" >> "${rc_conf}"
echo "export jail_$1_flags=\"-n $1 -l -U root\"" >> "${rc_conf} "
echo "export jail_$1_exec_start=\"/bin/sh /etc/rc\"" >> "${rc_conf}"
echo "export jail_$1_exec_stop=\"/bin/sh /etc/rc.shutdown\"" >> "${rc_conf}"

echo "jail.rcconf.def.create completed for $1"

********** This is the end of the script ***********



jail.rcconf.def.delete script:
This script requires a single parameters to function. It needs the jail cell name to delete. Use "ls /usr/local/etc/jail.conf to list all your jail cell names. After this script completes you need to run "jail.delete.jailcell " script to delete the jail cell's filesystem.

To Summarize the jail.rcconf.def.delete script:
  1. It starts by checking if the single required parameter is included.
  2. Prep some variables.
  3. Check to see if definition file exists.
  4. Check if jail cell is running.
  5. Delete fstab file.
  6. Delete the definition file
Instructions for creating this script
touch /usr/local/bin/jail.rcconf.def.delete
copy and paste the following script text into this file.
chmod 555 /usr/local/bin/jail.rcconf.def.delete
rehash


********** This is the start of the script **********
#!/bin/sh
# Did you pass the required parameters to this script like this.
# jail.rcconf.def.delete jailcellname

if [ $# -lt 1 ]; then
  echo " "
  echo "The required jail cell name parameter is missing."
  exit 2
fi

# Prep some variables
rc_conf="/usr/local/etc/jail.rcconf/$1"
rc_fstab="/usr/local/etc/jail.rcconf.fstab/$1"
console_log="/var/log/jail_$1_console.log"

# Check to see if definition file exists.
if [ ! -e "${rc_conf}" ]; then
   echo "This jail cell name does not exist $1"
   exit 2
fi
 
# Check if jail cell is running.
jail_list=`jls name`
for jail in ${jail_list}; do
  if [ "${jail}" = "$1" ]; then
    echo "Can not delete a definition file of a running jail cell"
    exit 2
  fi
done

# Delete the fstab file.
 rm "${rc_fstab}"

# Delete the rc.conf file.
rm "${rc_conf}"

# Delete the console.log file.
rm "${console_log}"

echo "jail.rcconf.def.delete completed for $1"

********** This is the end of the script ************



16.5.3 Starting & Stopping the rc.conf jail cells

The following two scripts named "jail.rcconf.start" and "jail.rcconf.stop" have been provided. These scripts have comments which self document what it's doing.

This script and all the other scripts can be downloaded as a single tar file.
See 16.10 How to download the script tar file for instructions.

jail.rcconf.start script:
This script requires a single parameter to function. It needs the jail cell name of the jail cell you want started.

Instructions for creating this script
touch /usr/local/bin/jail.rcconf.start
copy and paste the following script text into this file.
chmod 555 /usr/local/bin/jail.rcconf.start
rehash


********** This is the start of the script ***********
#!/bin/sh
# Did you pass the required parameters to this script like this.
# jail.rcconf.start jailcellname

if [ $# -lt 1 ]; then
  echo "Error: The required jail cell name parameter is missing."
  exit 2
fi

rc_conf="/usr/local/etc/jail.rcconf/$1"
if [ ! -e "${rc_conf}" ]; then
   echo "Invalid jail cell name. It does not exist."
   exit 2
fi

. "${rc_conf}"
/etc/rc.d/jail onestart $1 > /dev/null

if [ $? -ne 0 ]; then
  echo "Error: /etc/rc.d/jail failed to start rc.conf jail cell $1."
  echo "because of errors in $rcconf file."
  exit 2
else
  echo "jail.rcconf.start completed for $1"
fi

********** This is the end of the script ************



jail.rcconf.stop script:
This script requires a single parameter to function. It needs the jailcellname of the jail cell you want started.

Instructions for creating this script
touch /usr/local/bin/jail.rcconf.stop
copy and paste the following script text into this file.
chmod 555 /usr/local/bin/jail.rcconf.stop
rehash


********** This is the start of the script **********
#!/bin/sh
# Did you pass the required parameters to this script like this.
# jail.rcconf.stop jailcellname

if [ $# -lt 1 ]; then
  echo "Error: The required jail cell name parameter is missing."
  exit 2
fi

rc_conf="/usr/local/etc/jail.rcconf/$1"
if [ ! -e "${rc_conf}" ]; then
   echo "Invalid jail cell name. It does not exist."
   exit 2
fi

. "${rc_conf}"
/etc/rc.d/jail onestop $1 > /dev/null

if [ $? -ne 0 ]; then
  echo "Error: /etc/rc.d/jail failed to stop rc.conf type of jail $1."
  echo "because of errors in file $rc_conf."
  exit 2
else
  echo "jail.rcconf.stop completed for $1"
fi

********** This is the end of the script ************



16.5.4 Boot Starting & Shutdown Stopping of rc.conf jail cells

The following script named "jail.rcconf.bootime " has been provided. This script has comments which self document what it's doing.

This script and all the other scripts can be downloaded as a single tar file.
See 16.10 How to download the script tar file for instructions.

This is a rc.d-method type script because the rc.d system is the only way to implement boot time access to the jail system. To enable boot time start up of all the jail system's rcconf type of jail cells the host's /etc/rc.conf file needs this statement added, rcconf_enable="YES" and the jail.rcconf.bootime script has to be in the host's /usr/local/etc/rc.d directory with read/execute file permissions.

Note: For orderly stopping of the rcconf jail cells the host system must issue the "shutdown now" command. Using the reboot or halt commands just terminates the running jail cells. This may damage data bases running inside of jail cells.

Instructions for creating this script.
touch /usr/local/etc/rc.d/jail.rcconf.bootime
copy and paste the following script text into this file.
chmod 555 /usr/local/etc/rc.d/jail.rcconf.bootime
rehash


********** This is the start of the script **********
#!/bin/sh
# This script uses rc.conf definition statements in a file and the
# /etc/rc.d/jail for starting and stopping the jail cells.
# In the FreeBSD handbook "Chapter 16 Jails" this method is
# referred to as the Modern rc.d method.
#
# If  jailrcconf_enable="YES"  is coded in the hosts /etc/rc.conf file
# then this script will execute at boot time and shutdown time.
# This file must have execute permission "chmod 555 jail.rcconf.bootime"
# to work.
#
# The jail_stop routine below will only get executed if the host
# issues the "shutdown now" command.
# Using the reboot & halt commands just terminates all jails.
# This may damage data bases running inside of jails.

# PROVIDE: jailrcconf
# REQUIRE: LOGIN cleanvar
# BEFORE: securelevel
# KEYWORD: nojail shutdown

. /etc/rc.subr

name=jailrcconf
rcvar=`set_rcvar`
load_rc_config ${name}

jailrcconf_enable=${jailrcconf_enable:-"NO"}

start_cmd="jail_start"
stop_cmd="jail_stop"

jail_start()
{
  # Cycle through jail cells starting one at a time.
 
  rc_conf="/usr/local/etc/jail.rcconf"

  if [ -d "${rc_conf}" ]; then
    cd "${rc_conf}"
    jail_list=`ls`
  else
    echo "${rc_conf} not found"
    exit 2
  fi   

  for jail in ${jail_list}; do
    rc_conf="/usr/local/etc/jail.rcconf/$jail"
    . "${rc_conf}"     
    /etc/rc.d/jail onestart $jail > /dev/null
    if [ $? -ne 0 ]; then
       echo "Error: /etc/rc.d/jail failed to start jail cell ${jail}"
       echo "because of errors in file $rc_conf"
       exit 2
    else
       echo "rc.conf jail cell successfully started ${jail}"
    fi
  done
}

jail_stop()
{
  # Only stop jails that are currently running and belong to rc_conf.
  # Using the "jls" command to build list of jail names that are running.

  jail_list=`jls name`

  for jail in ${jail_list}; do
     rc_conf="/usr/local/etc/jail.rcconf/$jail"
     [ -e "${rc_conf}" ] || continue

     . "${rc_conf}"
     /etc/rc.d/jail onestop $jail > /dev/null
     if [ $? -ne 0 ]; then
        echo "Error: /etc/rc.d/jail failed to stop jail cell ${jail}"
        echo "because of errors in file $rc_conf"
        exit 2
     else
        echo "rc.conf jail cell successfully stopped  ${jail}"
     fi
  done
  }

run_rc_command $*

********** This is the end of the script **********



16.6 The Legacy rc.d Method

Since FreeBSD 4.0 when the /etc/rc.d/jail script first became available, all jail cells were based on jail cell definition statements being placed in the host's /etc/rc.conf file and the jail cell start / stop control accomplished by using /etc/rc.d scripts launched by the "service jail" command. This is now called the legacy rc.d method. What is documented here will work with all RELEASEs back to 4.0-RELEASE.

Other sources of useful information about the rc.conf definition statements are:
The rc.conf definition statements are covered in the 16.4.1 rc.conf Definition Statements section. In addition to those standard rc.conf definition statements, the jail_list="jailcellname...." statement is required one time and must be in front of all the jail cell definition statements that follow. In between the quotes you list the jail cell names separated by a space for all of the jail cell definitions.

You must hand edit the /etc/rc.conf file to insert your jail cell definition statements. Each jail cell defined this way must have a jail cell filesystem. You would use the jail.create.jailcell script to do that.

Adding the jail_enable="YES" statement to hosts /etc/rc.conf enables the starting of all jail cells defined in the host's /etc/rc.conf file at boot time and perform a orderly stopping of all running jail cells when the "shutdown now" command is issued from the host. Issuing the halt or reboot command on the host will just terminate the jail cell which may cause problems for database type applications running inside of the jail cell.



16.6.1 Starting & Stopping of Legacy rc.d jail cells

You issue the service(8) command on the host to start jail cells defined in the hosts /etc/rc.conf file. If the hosts /etc/rc.conf file contains the jail_enable="YES" statement then this format of the service command is available;

service jail start  means to start all jails defined if rc.conf
service jail start jailname   means to start only that jail
service jail start jailname jailname jailname  means to start only the jail names listed
service jail stop   means to start all jails defined if rc.conf
service jail stop jailname   means to start only that jail
service jail stop jailname jailname jailname  means to start only the jail names listed

If the jail_enable="YES" statement is commented out or missing from the hosts /etc/rc.conf file then this format of the service command is available

service jail onestart   means to start all jails defined if rc.conf
service jail onestart jailname   means to start only that jail
service jail onestart jailname jailname jailname  means to start only the jail names listed
service jail onestop   means to start all jails defined if rc.conf
service jail onestop jailname   means to start only that jail
service jail onestop jailname jailname jailname  means to start only the jail names listed

There is also the restart and onerestart command which first stops the jail cell and then starts the jail cell.

If the hosts /etc/rc.conf file contains the jail_enable="YES" statement then all jail cell definitions in /etc/rc.conf will be auto started at boot time and auto stopped in an controlled manner only if the shutdown command is issued on the host system. Commenting out the definition statements in the hosts /etc/rc.conf file for a selected jail cell is the only way of disabling that jail cell from being started at boot time, other that commenting out the jail_enable="YES" statement which disables all jail cells defined  in the hosts /etc/rc.conf files.



16.7 Working With Jail Cells

There are two jail cell related commands that are provided in the base system. The are;

jls
This command only runs on the host and lists all the running jail cells. It displays the jail cell name, the jail cells JID number, and the path to the jail cells mount point. The JID is a sequential number that gets assigned to each jail cell as it starts.  See jls(8) for details.

jexec
This command only runs on the host and is only used after the jail cell is started, it will open a root account session with the jail cell. Once your talking to the jail cell, you have all the normal abilities you would expect as the root user on the host. Entering exit will close down your session with the jail cell. You would code this command on the host command line this way jexec jailcellname tcsh  You can also use this host command to run commands in the jail cell, IE; jexec jailcellname ifconfig  See jexec(8) for details.


Installing applications inside of a jail.
To do so you need to be logged into the running jail cell. There is 3 ways this can be accomplished. From the host issue jexec jailcellname tcsh or from a remote computer using SSH or telnet. To do SSH, the jail cells Filesystem needs to have SSH enabled by running the the jail.ssh.jailcell script which is described here 16.3.3 Enabling Jail Cell SSH Support

Once you are logged in to the jail cell you can use the package system or the ports system to install applications in the normal way. By the very nature of the jail system, jail cells only need access to a ports filesystem during the population of the jail cell's applications.

When the jail cell needs to install an port version it's very simple to move the host's /usr/port filesystem to the jail cell like this;

mv /usr/ports /usr/jail/jailcellname/usr/

After which the port filesystem will be usable from within that jail cell after the jail cell has been started. When that jail cell no longer needs it, or the host system needs to use it, it's just as simple to move it back to the host.

mv /usr/jail/jailcellname/usr/ports /usr/


Using /usr/src inside of a jail cell.
The host's /usr/src filesystem can be moved back and forth between the host and the jail cell just as easily as the /usr/port Filesystem can be.


Updating the applications running in the jail cell.
As long as the host and the sharedfs stay in sync, and the update is form the one sub-RELEASE to the next sub-RELEASE,  IE; 9.0-RELEASE to 9.1-RELEASE the installed ports/packages do not need reinstalling. If the host updates from a major RELEASE to the next major RELEASE, IE; 8.3-RELEASE to 9.0-RELEASE then all the ports/packages installed in the jail cells need to be updated also, just like they have to be on the host.



16.8 Summary of the provided Scripts & Their Usage

jail.pristine.fetch                Populate template with pristine copy of FreeBSD
jail.install.system               Build the third generation jail system filesystems

jail.create.jailcell               Create the jail cell filesystem.
jail.delete.jailcell                Delete the jail cell filesystem

jail.jailconf.def.create        Create the jail.conf definition statements file
jail.jailconf.def.delete         Delete the jail.conf definition statements file
jail.jailconf.start                 Start a jail.conf jail cell
jail.jailconf.stop                 Stop a jail.conf jail cell
jail.jailconf.bootime           Boot time auto start & shutdown auto stop for jail.conf jail cells

jail.rcconf.def.create          Create the modern rc.conf definition statements file
jail rcconf.def.delete           Delete the modern rc.conf definition statements file
jail rcconf.start                   Start a modern rc.conf jail cell
jail.rcconf.stop                   Stop a modern rc.conf jail cell
jail.rcconf.bootime             Boot time auto start & shutdown auto stop for modern rc.conf jail cells



16.9 Jail Cell Network Traffic Flow

Things which effect how individual jail cells are going to function.

Viewed from the NIC facing the public internet;

  1. Host Firewall;
    All traffic is processed first by the host's firewall.

  2. Public Routable IP Address;
    Under public network conditions the normal way for unsolicited service requests to reach your NIC facing the public internet is through the use of a registered domain name. Each registered domain name has a associated IP address that gets routed by your ISP to your NIC that's connected to your ISP. This is how the public internet works and is out side of the control of FreeBSD jail systems.

    Most home users don't have the luxury of purchasing static IP addresses from their ISP's. Static IP addresses are permanent, they will never change unlike dynamic IP addresses. Home service comes with a single dynamic IP address. The ISP may at any time change the dynamic IP address they have assigned you. Your operating system can automatically handle this on the fly without you even being aware it happened. If the home user has a registered domain name using the dynamic IP address to direct unsolicited traffic to their host, it will stop working every time the dynamic IP address changes. Some domain registrar's have a service where you run a program on your host that watches for the dynamic IP address to change and when it does, it updates the domain name to use the new dynamic IP address for routing traffic.

    All the traffic for that single public routable dynamic IP address is going to be processed by the host. If you assigned that same public routable IP address to 3 jail cells, Then all traffic to that single IP address will be processed first by the host and then by each of those 3 jail cells. This is a problem. This is when the port number comes into play. Lets say jail cell #1 is a web server and as such is listening on port 80. As long as the host, jail cell #2 and jail cell #3 have no applications listening on port 80, then jail cell #1 will be the only jail cell processing the port 80 traffic for that IP address. This concept is true for all port numbers. In this situation you would create the jail cell definition assigning that single public routable dynamic IP address to all 3 jail cell and exclude using the "interface" parameter.

    Now lets say you have purchased 3 static public routable IP addresses, you assign one for the host and the other two have registered domain names that point to them. In this case the host/jail cell processing flow is different. In this situation the IP addresses with separate domains can be assigned to jail cells and then inbound traffic will first be processed by the hosts firewall and then passed directly to the assigned jail cell without the host processing the traffic. Each of those two jail cells will have access to all the port numbers without the host or other jail cells being aware of that traffic. The host and the two jail cells can be running a web server without any interference from each other. This is the intended way that jail cells were designed to function. In this situation you would create each jail cell definition assigning one of the static IP addresses to the jail cell and include the "interface" parameter with the interface device name of the NIC facing the public internet.

  3. LAN Routable IP Address;
    There are 2 ways a jail cell can be utilized on the Local area network, they are; local internal LAN access only, or local internal LAN access with access to the public internet.

    For local internal LAN access only, the jail cell might contain a web server application or the internal email server, could also be jail cells that LAN users login into with SSH or telnet to have their own FreeBSD operating system to play with. In this situation you would create each jail cell definition assigning one of the private non-public routable IP address to the jail cell and include the "interface" parameter with the interface device name of the NIC facing the internal LAN.

    For local internal LAN access with access to the public internet. The jail cell can be accessible by all work stations on the LAN as a email server or a jail cell under development requiring internet access to install ports or packages. In this situation you would create each jail cell definition assigning one of the private non-public routable IP address to the jail cell and include the "interface" parameter with the interface device name of the NIC facing the public internet. In addition, the IP address traffic needs to be NATed, (IE; network address translation) before it can be routed to the public internet. This is easily accomplished using a firewall NAT service. Doing so will enable jail cells with private non-public routable IP address to gain outbound access to the public internet. Of the three firewall solutions provided in the base system of the host, I find IPFILTER has the easiest NAT service to configure. In this situation you would create each jail cell definition assigning one of the private non-public routable IP address to the jail cell and include the "interface" parameter with the interface device name of the NIC facing the public internet.

  4. Port numbers;
    For hosts with a single public routable IP address, the general rule is, the host processes all network traffic so the jail system administrator has to insure the selected port number is only processed by the host or a jail cell but not both. This means the host can not be running a apache server listening on port 80  and some jail cell doing the same thing. The host will process all the port 80 traffic and the jail cells will never see any of the traffic.

  5. NIC Device Name;
    The jail.jailconf.def.create and jail.rcconf.def.create scripts create the 2 different types of jail cell definition statements. Both scripts require the jail cell name and the IP address to assign to the jail cell. The NIC device name is optional, but it's use is necessary for all situation except when multiple jail cells are being assigned the same single host public routable dynamic IP address. When the NIC device name is entered, the jail cell definition "interface" parameter gets populated with the entered value. When the jail cell is started an alias will automatically be created for the jail cell's IP address on that NIC device name and automatically removed when the jail cell is stopped. In most situations this is required to direct traffic to the jail cell.

  6. DHCP  LAN IP Addresses;
    The jail system administrator has to be aware of the LAN IP addresses under the control of the host's DHCP server. If a DHCP LAN IP address is assigned to a jail cell, when the jail cell starts the LAN PC using that IP address will lose it's connection.


16.10 How to download the script tar file

The tar file containing all the scripts documented here can be downloaded by entering the following commands on the hosts root console command line.

mkdir /download
cd /download
ftp http://downloads.sourceforge.net/project/qjail/handbook/jail.scripts.tar.bz2
mkdir /scripts
cd /scripts
tar xpf /download/jail.scripts.tar.bz2
mv jail.rcconf.bootime /usr/local/etc/rc.d
mv jail.jailconf.bootime /usr/local/etc/rc.d
cp jail* /usr/local/bin
rehash
cd /
rm -r /download /srcipts

jordan 6 sport blue foamposites black suede legend blue 11s louis vuitton outlet black infrared 6s jordan 3 sport blue retro jordans retro jordans black infrared 6s legend blue 11s coach outlet online louis vuitton outlet cheap jordans lebron 12 louis vuitton outlet jordan retro 6 beats by dre outlet retro jordans foamposites black suede legend blue 11s cheap jordan shoes jordan 6 sport blue jordan retro 6 black infrared 6s louis vuitton outlet sac louis vuitton louis vuitton outlet louis vuitton outlet cheap louis vuitton jordan 6 black infrared legend blue 11s jordan 11 legend blue louis vuitton outlet legend blue 11s kate spade outlet black infrared 6s jordan 3 sport blue jordan 3 sport blue beats by dre outlet coach outlet