Jail Basics - fsbruva/thebrig GitHub Wiki

In FreeBSD (as well as Linux), there are two main pieces that make up the operating system: the kernel and userland. The kernel is the core of the operating system, and is a specialized program that is customized for the CPU architecture of the computer. The kernel manages all the other programs on the system, as well as manages communication to and from the hardware of the system. In this way, the userland programs only need to know how to speak to the kernel, because the kernel has pre-established methods of performing actions. The userland programs don't have to worry about what kind of video card you have, or the hard drive sector size because the kernel takes care of that.

FreeBSD has a mechanism in the installed operating system's kernel to listen to instructions from a completely separate set of userland programs. The kernel knows that this other userland is of limited privilege, and will not allow it to modify anything on the full operating system. Due to the significant restrictions that the kernel places on this other userland, it was named a "jail." The jail is made up of all the files of a copy of FreeBSD, but shares the kernel with the host operating system. These files are located someplace on the filesystem, say at /mnt/zpool2/jail_1. If you copied a file into that directory, the jail would see it at /, the root of the filesystem. An intelligent user might be able to use some tricks to detect that they were in a jail, but the operating system in the jail doesn't know any different. It has access to a kernel, and has all the files it needs to be an OS. The default setting is that the jail cannot access ANYTHING outside of its home folder, except the kernel. Due to the fact that the jail and the host system have a common kernel, FreeBSD jails are known as para-virtualized operating systems.

You might be asking yourself, "Why would you want this?" There are a few reasons:

Security - The host operating system's files are protected from access by the jail, and any user inside the jail. For this reason, if a jail gets hacked and the hacker obtains root access - they can't do any harm to your main system. This is a HUGE benefit, especially if the jail is accessible from the internet - hackers might stop your media server, but your NAS will be happy as a clam. You can simply shutdown and wipe the jail out and rebuild it from a backup and be up and running in no time!

Compatibility - The host operating system's files in userland do not affect the jail's. For example, if you are running one application on the host that requires Perl 5.12, but you want to install another piece of software that only supports up to Perl 5.8 - you will not be able to. In this case, you create a jail and install Perl 5.8 and your other piece of software in it, and though you have two copies of Perl running, neither of them know that. This is VERY important because if you try to install certain packages to Nas4Free, it can break the software versions.

Ease of Remote Administration - Since the jail's running or not does not affect the host system, it is very easy to restart a jail to complete an installation. If the jail cannot start for some reason - it only affects the jail, rather than your SSH, FTP and other functions your NAS is taking care of on your network.

Flexibility - The jailed copy of FreeBSD is totally oblivious to the underlying operating system. It only really cares about the major version of the kernel it's using. This is a big deal because as you upgrade the host Nas4Free or FreeBSD version, the jail just keeps on trucking - even on an embedded Nas4Free installation, because the jail lives on one of your zfs pools or other hard disk.