BSD DevCenter
oreilly.comSafari Books Online.Conferences.


Virtualization with FreeBSD Jails

by Dan Langille

This article shows how I created a jail under FreeBSD 5. Though FreeBSD 6.0 has come out since I wrote this article, the strategy should remain the same. I'll update the article with any changes should anything be different.

I have written previously about jails on FreeBSD 4. The goal of this jail is the creation of a test environment for a project I've been working on. Until recently, I've been providing a dedicated machine for exclusive use by the Bacula network backup project. That system ran regression tests on FreeBSD. In a recent consolidation of hardware, I replaced several older machines with one newer machine. I wanted to dispose of the computer used by the Bacula project and move them to a more powerful computer. However, I didn't want them to have exclusive use of this system. I wanted to use the same computer and not have us interfere with each other.

Lift and Separate

Jails can separate different processes and keep them apart so they cannot interfere with each other. For example, you could run Apache in a jail and keep it away from everything else on the machine. Should someone find an exploit in Apache and use it to compromise your system, the intruders can only do what the jail allows them to do. A jail can consist of a full operating system, or a single executable.

The solution I used was to create a virtual machine for use by the Bacula project. I had recently acquired a Pentium 4 2.4GHz machine. It was pretty fast, so I decided to use this for system for my own development purposes. It will also be sitting idle for long periods of time, so I might as well let some else use it, as well. I don't want them to have access to the things I'm working on, so I decided to put them in a jail.

From within a jail, they are chrooted and cannot see anything outside of the jail. At the same time, it appears to them as if they are running on their own machine with their own operating system. As far as they know, they have their own computer and nobody else is on the system.

Running a virtual system within a jail is a good solution if you want to provide someone with resources, but don't want them to have complete control over your system. A jail can help you deal with issues of security and access, and improve the usage of existing resources, all at the same time.

Jail Documentation

The main document for creating a jail is man jail. I followed the instructions listed under "Setting up a Jail Directory Tree." I used those instructions to create the jail. You will need the full source tree for the system you going to create. I used the /usr/src/ directory I had from my most recent build world.

There's one step from man jail that I did not follow. I left Sendmail (actually, Postfix) running. I just changed it so that it did not listen on all IP addresses. I added this setting to /usr/local/etc/postfix/

inet_interfaces = $myhostname

That allows the jail to run its own mail server.

I put my jail at /home/jail/ This is the value I assigned to D in the instructions. After you have installed the jail, if you peek inside that directory, you'll see it looks just like the root directory of a typical FreeBSD system:

[dan@dfc:/home/jail/] $ ls
COPYRIGHT       etc       libexec        root           usr
bin             home      mnt            sbin           var
boot            kernel    proc           sys
dev             lib       rescue         tmp
[dan@dfc:/home/jail/] $

Terminology: Host Versus Jail

The host environment is the main system and is where you first install FreeBSD on the computer. It is in the host environment that you create a jail. The Bacula project will do their testing in the jail. They have access to the jail and only the jail. They will not have access to the host environment at all.

This concept of host environment and jail environment will come up again in this article. It is important that you understand what each one is.

In this example, the host environment is at IP address and the jail is at

Modifying Other Daemons

Most daemons will listen to whatever IP addresses are available to them. After starting your jail, if you try to ssh to it, you will not get into it. You'll be in the host environment instead. To get into the jail environment via ssh, you need to:

  • Tell the host environment sshd not to listen to the jail's IP address.
  • Run sshd in the jail.

Host Environment syslogd

This entry in /etc/rc.conf tells syslogd to not listen on any IP address.


That allows syslogd to run in both the host and the jail environments.

Host Environment inetd

This entry in /etc/rc.conf tells inetd to listen on a specific IP address. This address is that of the host environment:

inetd_flags="-wW -C 60 -a"

Note that the first part of the flags in that line is from /etc/defaults/rc.conf:

inetd_flags="-wW -C 60" # Optional flags to inetd

Host Environment sshd

To alter the host environment sshd so it listens only to host environment IP addresses, modify /etc/ssh/sshd_config and set the IP address for the Listen directive:


Then restart the main sshd process:

kill -HUP `cat /var/run/`

Use telnet to verify that the host environment is not listening on the jail address:

$ telnet 22
telnet: connect to address Connection refused
telnet: Unable to connect to remote host

If you don't get a connection, the host environment is not listening. This assumes that you have not yet started sshd in the jail environment.

Jail Environment sshd

To start sshd in the jail environment, add the following line to /etc/rc.conf:


Jail Environment syslogd

In addition, I also swapped console output to /var/log/messages, as shown in this snippet from /etc/syslogd.conf:

#*.err;kern.warning;auth.notice;mail.crit    /dev/console
*.err;kern.warning;auth.notice;mail.crit     /var/log/messages

Pages: 1, 2

Next Pagearrow

Sponsored by: