THE
DEFINITIVE GUIDE TO CHROOTING
The Definitive Guide To Chrooting
INTRODUCTION
What
This document describes a general process for chrooting services
running on a Linux based operating system. It is assumed that you are
already familiar with basic UNIX systems administration, although some
explanations are given where I fell they are warranted. If you are not
already familiar with this, I would not recommend undertaking this
process at this time, as the errors which will inevitably occur will be
a nightmare to troubleshoot without this knowledge. You do not need to
be a C guru, or for that matter a networking guru. But a basic
famliarity with the processes described in here is definitely needed.
It was written because, although I was able to find documents and
HOWTOs explaining how to chroot individual services, I could find no
general framework document explaining the process behind it. Several
services will be used as examples here, as they will apply in different
situations. Keep in mind though, that this process must be interpreted
and adapted for each service you will be chrooting using this method.
No one service can be chrooted in the same way as another.
It is not a guide to securing your services. While some suggestions
will be given for the sake of clarity, I cannot possibly cover the
security of each and every application you may wish to chroot with this
process. Chrooting in and of itself is another layer of security, but
it is not the last. There are plenty of good quality guides and HOWTOs
available on how to secure most services available for your system. I
suggest reading the documentation on the developer website, or looking
at The Linux Documentation Project, at www.tldp.org
Why
I will not explain the benefits and risks of chrooting your services. I
assume that if you are reading this, you already know what these are.
However, I would like to comment on one distinct advantage of chrooting
all your services, as opposed to chrooting only a few to limit exposure
to risk. Once all your services have been chrooted, it becomes a simple
matter to control inter process communication via a firewall over the
loopback interface. This provides for a much finer grain of control
over your process communications and data flow than do normal POSIX
permissions.
Where
There is no official home for this document as of yet. Hopefully
somebody will offer me one.
How
I wrote this document based on my experiences after chrooting all my
public services on my home server. I was rather frustrated with lack of
documentation on the process, and with the assumption that what applies
to one version of a service will apply to the next. I found that these
documents went out of date rather quickly. After chrooting most of my
services on several server build, I learned a general process for doing
so by trial and error. This document is the end result of all those
errors. It is the order that comes from my chaos.
While this method works for me, on my systems, it may not work for you.
Every attempt has been made to make this document as general as
possible, but a process such as this can never apply to everything. I
welcome any and all comments and suggestions for improvements. Even
insults are welcome if they make me laugh.
CREATING A TEMPLATE
The first and most helpful step in this process is to create a template
to use as a reference when building the chroot jail. To do this,
compile the application as normal, but install it to an independent
directory, such as /usr/local/named, in the case of bind. The idea is
to have available to you a sample of what the jail will look like once
it has been built. Do not configure the application to install to the
root of your filesystem, such as with a prefix of / or /usr. This will
intersperse the installed files with the rest of the system and make
them nearly impossible to find. If they are sitting on their own in a
seperate, independent directory, you will easily be able to see which
files you need to install to the chroot jail.
Once the tamplate has been made, do a make distclean in the root of the
source tree of the application you are working on. This will delete any
files created by the configuration and compilation process, and any
saved configuration and cache files as well. In other words, you will
be starting from scratch. If distclean is not a valid make target, a
make clean will usually work. Otherwise, you can always just delete the
source tree and re-extract it. Once a template has been made, you are
ready to begin the process of building the application to function
within the chroot jail.
CONFIGURING THE APPLICATION
The first rule, and most important rule, of chrooting any service, is
to build that service from source code. Most applications come with
easily configurable and compilable source code packages ready for
download. Have a look at the README and INSTALL files for the steps
necessary to compile each service you will chroot with this method. It
would be quite difficult, if not impossible, to chroot most services
using precompiled packages, as the directory search paths are quite
often hardcoded into the binaries and not user configurable. The second
rule of chrooting a service is:
DO NOT CONFIGURE SERVICES TO INSTALL TO YOUR CHROOT DIRECTORY!
That is, suppose you are installing your name server to /chroot/named.
Do not configure it with a configure option such as
Code:
./configure –prefix=/chroot/named
This will create a whole host of references within the application
itself to /chroot/named, but while chrooted, /chroot/named is actually
the root of named's filesystem. While this can be solved, if necessary,
by creating a symlink within the chroot directory, such as
/chroot/named => /, this will force every last library lookup and
function call to resolve that reference, using unnecessary CPU time. It
also creates configuration nightmares. This is a very common mistake.
In general, configure everything to the root directory, or /usr, if
that is what you prefer. Make sure also that system configuration
directories are explicitly specified on the command line, such as /etc,
or /var/mysql in the case of mysql. A simple configuration line for a
chrooted mysql server would look like this, to avoid unnecessary
/chroot/mysql lookups and storing databases in /chroot/mysql/var/mysql:
Code:
./configure –prefix=/usr –sysconfdir=/etc –localstatedir=/var/mysql
Other configuration options can be specified as needed, usually without
problems. The goal is to eliminate the need for a /chroot/[app] => /
symlink within the jail, creating an environment which will be
indistinguishable to the service from your system. Once configured,
compile the application as you normally would.
INSTALLING THE APPLICATION
Some packages have an option available which allows you to install the
compiled code to a directory other than the one you specified on the
configure line, usually with something like:
Code:
INSTALL_DIR=/chroot/mysql make install[
This is the easiest method. Unfortunately, not all packages come with
this option. You could edit the Makefiles manually, however, this often
proves to be rather complicated. Failing the ability to install to a
directory you did not configure the package for, you must install the
needed files manually by copying them into the chroot jail. This is
easier if you first configure and build the application to install to
an independent directory, such as /usr/local/mysql. You can then check
that directory for any files which are installed normally. Then, after
configuring & compiling to the root, you have a template of what
the chroot jail should look like. Be aware, however, that some
configuration scripts ignore the /usr/local/mysql prefix and install
configuration files to /etc anyway. Check certain likely directories
for the presence of these files, such as /etc /var, and others which
may be subject to this behaviour.
Setting up the jail environment
You should have some idea of what the jail will eventually look like,
having first set up a template installation. The first step in creating
the jail is to create the necessary directories within it. A basic
directory structure within the jail will include directories for
configuration files, logfiles, binary files, etc.... In the case of
Apache httpd, the following is a list of the basics:
Code:
/chroot/httpd/lib
/chroot/httpd/bin
/chroot/httpd/tmp
/chroot/httpd/var
/chroot/httpd/var/log
/chroot/httpd/var/logs
/chroot/httpd/etc
/chroot/httpd/dev
/chroot/httpd/home
Check the template directory you created for a complete list of the
directory structure you will need; be sure to also set the permissions
and ownerships on these directories appropriately. /tmp and /var/logs,
for example will need to be writeable by the user that Apache is
running as. Apache may also need read permissions for the /home
directory, if you are serving user pages as well, and will surely need
read access to the document root (usually /var/www). The next step is
to copy any of the needed binaries that were compiled earlier into the
chroot jail. For MySQL, this would include the mysql client and the
mysqld daemon. Apache httpd is more complicated. It requires the
lt-httpd (or httpd) server binary, the apachectl control script, php
(usually), if compiled with php support, apxs, and others. Each
application will require a different set of binaries to be installed to
the jail in order to function. This is the purpose behind first
installing the application to an independent directory, such as
/usr/local/httpd (in the case of Apache httpd). Some binaries may be
located in /bin, and others in /usr/bin. Others still will be in
/usr/libexec. They may also be installed to /usr/bin and /usr/sbin if
appropriate configuration options were given to the configuration
script. But most importantly, keep the binaries in the same relative
location in the chroot jail that they have been configured to, as many
paths, for other binaries, scripts, and library files, will be
hardcoded into the binaries. Once the binaries have been installed, we
are ready to create a basic chroot jail environment.
Before the application can run, certain necessary files, beyond the
application binaries, must be in place. Let us take the example of
chrooting mysql. In most cases, mysql is run as the mysql user. In
order for the mysql daemon to run as the mysql user, it must have
available in the /etc directory a copy of the passwd, shadow, and group
files containing the necessary entries that make the mysql user valid
on your system. Copy the lines from those files which are relevant to
the application you are chrooting. Next, there are a few other files in
/etc you should copy to the chroot jail. These include, but are not
limited, to the following:
Code:
HOSTNAME
nsswitch.conf
localtime
hosts.allow
hosts.deny
hosts.equiv
magic
ld.so.conf
services
pam.d/* (if you use PAM for authentication)
This will give the chrooted application a working environment. One
trick I use is to create a generic /chroot/etc directory, and then hard
link these files from there. That way, I only need to change any one of
the files in /chroot/etc, and the change is instantly reflected across
all the chrooted services.
Now, once the files and directories are in place, we still do not have
an appropriate user environment. We must still set the necessary
permissions on many of these objects. /tmp, for example, must be
writeable by whatever applciation will be using the jail. /etc/shadow
must not be world readable. In the case of mysql, the /var/mysql
directory must be writeable by the mysql user. In the case of apache
httpd, the /var/www directory must be readable by whatever user apache
runs as. Make sure the necessary permissions are set to ensure a sane
operating environment.
Original Tutorial
Submitted by Striek for TheTAZZone-TAZForum
Originally posted on June 11th, 2006 here
Do not use, republish, in whole or in part, without the consent of
the Author. TheTAZZone policy is that Authors retain the rights to the
work they submit and/or post...we do not sell, publish, transmit, or
have the right to give permission for such...TheTAZZone merely retains
the right to use, retain, and publish submitted work within it's
Network.