os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Integrate later Introduction into the Synopsis of the Jails chapter.

Browse source 
Sponsored by:	iXsystems
This commit is contained in:
Dru Lavigne 2014-04-09 20:11:05 +00:00
parent 1aa01eb97a
commit 9dbcd11a7e
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=44513
1 changed files with 91 additions and 144 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

235
en_US.ISO8859-1/books/handbook/jails/chapter.xml
View file

@ -18,34 +18,90 @@
<sect1 xml:id="jails-synopsis">
<title>Synopsis</title>
<para>This chapter will provide an explanation of what &os; jails
are and how to use them. Jails, sometimes referred to as an
enhanced replacement of
<emphasis>chroot environments</emphasis>, are a very powerful
tool for system administrators, but their basic usage can also
be useful for advanced users.</para>
<para>Since system administration is a difficult
task, many tools have been developed to make life easier for
the administrator. These tools often enhance
the way systems are installed, configured, and
maintained. One of the tools which can be used to enhance the security
of a &os; system is <firstterm>jails</firstterm>. Jails have
been available since &os;&nbsp;4.X and continue to be
enhanced in their
usefulness, performance, reliability, and security.</para>
<important>
<para>Jails are a powerful tool, but they are not a security
panacea. It is particularly important to note that while it
is not possible for a jailed process to break out on its own,
there are several ways in which an unprivileged user outside
the jail can cooperate with a privileged user inside the jail
and thereby obtain elevated privileges in the host
<para>Jails build upon the &man.chroot.2; concept, which is used to
change the root directory of a set of processes, creating a
safe environment, separate from the rest of the system.
Processes created in the chrooted environment can not access
files or resources outside of it. For that reason,
compromising a service running in a chrooted environment
should not allow the attacker to compromise the entire system.
However, a chroot has several limitations. It is suited to easy tasks which do not
require much flexibility or complex, advanced features. Over time
many ways have
been found to escape from a chrooted environment, making it
a less than ideal solution for
securing services.</para>
<para>Jails improve on the concept of the traditional
chroot environment in several ways. In a traditional
chroot environment, processes are only limited in the
part of the file system they can access. The rest of the
system resources, system users, running
processes, and the networking subsystem are shared by the
chrooted processes and the processes of the host system.
Jails expand this model by virtualizing access to the
file system, the set of users, and the networking
subsystem. More
fine-grained controls are available for tuning the
access of a jailed environment.</para>
<para>A jail is characterized by four elements:</para>
<itemizedlist>
<listitem>
<para>A directory subtree: the starting point from
which a jail is entered. Once inside the jail, a process
is not permitted to escape outside of this subtree.</para>
</listitem>
<listitem>
<para>A hostname: which will be used
by the jail.</para>
</listitem>
<listitem>
<para>An <acronym>IP</acronym> address: which is
assigned to the jail. The <acronym>IP</acronym> address of a jail is
often an alias address for an existing network
interface.</para>
</listitem>
<listitem>
<para>A command: the path name of an executable to
run inside the jail. The path is relative to the
root directory of the jail environment.</para>
</listitem>
</itemizedlist>
<para>Jails have their own set of users
and their own <systemitem class="username">root</systemitem> account which
are limited
to the jail environment.
The <systemitem class="username">root</systemitem>
account of a jail is not allowed to perform operations
to the system outside of the associated jail
environment.</para>
<para>Most of these attacks can be mitigated by ensuring that
the jail root is not accessible to unprivileged users in the
host environment. Regardless, as a general rule, untrusted
users with privileged access to a jail should not be given
access to the host environment.</para>
</important>
<para>This chapter provides an overview of jail terminology
are how to use &os; jails. Jails are a powerful
tool for system administrators, but their basic usage can also
be useful for advanced users.</para>
<para>After reading this chapter, you will know:</para>
<itemizedlist>
<listitem>
<para>What a jail is, and what purpose it may serve in &os;
<para>What a jail is and what purpose it may serve in &os;
installations.</para>
</listitem>
@ -59,25 +115,21 @@
</listitem>
</itemizedlist>
<para>Other sources of useful information about jails are:</para>
<important>
<para>Jails are a powerful tool, but they are not a security
panacea. While it
is not possible for a jailed process to break out on its own,
there are several ways in which an unprivileged user outside
the jail can cooperate with a privileged user inside the jail
to obtain elevated privileges in the host
environment.</para>
<itemizedlist>
<listitem>
<para>The &man.jail.8; manual page. This is the full
reference of the <command>jail</command> utility &mdash; the
administrative tool which can be used in &os; to start,
stop, and control &os; jails.</para>
</listitem>
<listitem>
<para>The mailing lists and their archives. The archives of
the &a.questions; and other mailing lists hosted by the
&a.mailman.lists; already contain a wealth of material for
jails. It should always be engaging to search the archives,
or post a new question to the &a.questions.name; mailing
list.</para>
</listitem>
</itemizedlist>
<para>Most of these attacks can be mitigated by ensuring that
the jail root is not accessible to unprivileged users in the
host environment. As a general rule, untrusted
users with privileged access to a jail should not be given
access to the host environment.</para>
</important>
</sect1>
<sect1 xml:id="jails-terms">
@ -141,111 +193,6 @@
</variablelist>
</sect1>
<sect1 xml:id="jails-intro">
<title>Introduction</title>
<para>Since system administration is a difficult and perplexing
task, many powerful tools were developed to make life easier for
the administrator. These tools mostly provide enhancements of
some sort to the way systems are installed, configured and
maintained. Part of the tasks which an administrator is
expected to do is to properly configure the security of a
system, so that it can continue serving its real purpose,
without allowing security violations.</para>
<para>One of the tools which can be used to enhance the security
of a &os; system are <emphasis>jails</emphasis>. Jails were
introduced in &os;&nbsp;4.X by &a.phk.email;, but were greatly
improved in &os;&nbsp;5.X to make them a powerful and flexible
subsystem. Their development still goes on, enhancing their
usefulness, performance, reliability, and security.</para>
<sect2 xml:id="jails-what">
<title>What is a Jail</title>
<para>BSD-like operating systems have had &man.chroot.2; since
the time of 4.2BSD. The &man.chroot.8; utility can be used to
change the root directory of a set of processes, creating a
safe environment, separate from the rest of the system.
Processes created in the chrooted environment can not access
files or resources outside of it. For that reason,
compromising a service running in a chrooted environment
should not allow the attacker to compromise the entire system.
The &man.chroot.8; utility is good for easy tasks which do not
require much flexibility or complex, advanced features. Since
the inception of the chroot concept, however, many ways have
been found to escape from a chrooted environment and, although
they have been fixed in modern versions of the &os; kernel, it
was clear that &man.chroot.2; was not the ideal solution for
securing services. A new subsystem had to be
implemented.</para>
<para>This is one of the main reasons why
<emphasis>jails</emphasis> were developed.</para>
<para>Jails improve on the concept of the traditional
&man.chroot.2; environment in several ways. In a traditional
&man.chroot.2; environment, processes are only limited in the
part of the file system they can access. The rest of the
system resources (like the set of system users, the running
processes, or the networking subsystem) are shared by the
chrooted processes and the processes of the host system.
Jails expand this model by virtualizing not only access to the
file system, but also the set of users, the networking
subsystem of the &os; kernel and a few other things. A more
complete set of fine-grained controls available for tuning the
access of a jailed environment is described in
<xref linkend="jails-tuning"/>.</para>
<para>A jail is characterized by four elements:</para>
<itemizedlist>
<listitem>
<para>A directory subtree &mdash; the starting point from
which a jail is entered. Once inside the jail, a process
is not permitted to escape outside of this subtree.
Traditional security issues which plagued the original
&man.chroot.2; design will not affect &os; jails.</para>
</listitem>
<listitem>
<para>A hostname &mdash; the hostname which will be used
within the jail. Jails are mainly used for hosting
network services, therefore having a descriptive hostname
for each jail can really help the system
administrator.</para>
</listitem>
<listitem>
<para>An <acronym>IP</acronym> address &mdash; this will be
assigned to the jail and cannot be changed in any way
during the jail's life span. The IP address of a jail is
usually an alias address for an existing network
interface, but this is not strictly necessary.</para>
</listitem>
<listitem>
<para>A command &mdash; the path name of an executable to
run inside the jail. The path is relative to the
root directory of the jail environment.</para>
</listitem>
</itemizedlist>
<para>Apart from these, jails can have their own set of users
and their own <systemitem class="username">root</systemitem> user. Naturally, the
powers of the <systemitem class="username">root</systemitem> user are limited
within the jail environment and, from the point of view of the
host system, the jail <systemitem class="username">root</systemitem> user is not an
omnipotent user. In addition, the <systemitem class="username">root</systemitem>
user of a jail is not allowed to perform critical operations
to the system outside of the associated &man.jail.8;
environment. More information about capabilities and
restrictions of the <systemitem class="username">root</systemitem> user will be
discussed in
<xref linkend="jails-tuning"/> below.</para>
</sect2>
</sect1>
<sect1 xml:id="jails-build">
<title>Creating and Controlling Jails</title>
@ -322,7 +269,7 @@
<para>Once a jail is installed, it can be started by using the
&man.jail.8; utility. The &man.jail.8; utility takes four
mandatory arguments which are described in the
<xref linkend="jails-what"/>. Other arguments may be specified
<xref linkend="jails-synopsis"/>. Other arguments may be specified
too, e.g., to run the jailed process with the credentials of a
specific user. The
<option><replaceable>command</replaceable></option> argument