لطفا منتظر باشید ...
What Is a chroot Jail?
Linux's directory system is built on a root ( / ) directory. All
directories fall off of this one, and can be referred to relative to the root
directory. A chroot jail effectively changes the root directory (hence the name) to
something else, as illustrated in
instance, if you set aside /opt/chroot as a new root directory for a server, all file references made by
the server will be relative to /opt/chroot rather than the true root
directory. Thus, even if a server is compromised and the attacker uses it to
modify, say, /etc/passwd , the modification will actually
affect /opt/chroot/etc/
passwd , which is not nearly as serious a matter as
a change to the real /etc/passwd .
Figure 23.1. A chroot jail creates a special environment
that contains only those files required for a particular server to run.
call known as chroot() , often as used by a program called chroot . You can set up a chroot jail
either by using a server that handles the matter itself with its own chroot() call
or by using the chroot program to launch the server. These issues are described in more
detail shortly, in the section "
Jail ."The entire chroot jail system has
several important consequences and implications: If a program relies on configuration files, uses
dynamic libraries, accepts or delivers files, or otherwise manipulates any
local files, those files must exist within the chroot environment. This requirement can result in a very large chroot environment directory tree if the server requires many support files. One
exception is that if the server implements its own chroot() call, and if it
reads the support files before making the chroot() call,
those support files should exist outside of the chroot environment. A server running in a chroot jail
can access only those files that reside within the same jail. This means that
you should keep extraneous files within that environment to a minimum to give
the jailed tool as little opportunity to do mischief as possible. A corollary of the preceding consequence is that
if you run multiple servers in chroot jails, you should create separate jails for each of them. This minimizes the chance
that a bug in one server could be used to reconfigure the other server, thus
giving the attacker greater access to your system. Because the chroot jail environment
exists as a subdirectory within the normal Linux directory tree, programs that
are not run from a chroot jail can place
files within the jail. This can be a convenience or a potential security risk,
depending upon your point of view. This point is further elaborated in the
upcoming section, "
Environment ."Although a chroot jail sounds like a
great way to minimize the risk of running servers, it's not without its
drawbacks and limitations. One of these is that not all servers operate well in
chroot jails. Some, such as most FTP servers using anonymous mode and some
mail servers, are designed to operate partly or wholly in a chroot jail. Others,
like Telnet servers, require more-or-less complete access to the normal Linux
system in order to do their jobs. Thus, you can't simply set up all your
servers to operate in chroot jails, although you can do this with some.Because most chroot jails are
configured by the system administrator rather than set up automatically by
package management systems, it's possible to overlook the chroot server
after you upgrade the server package. You must remember to recopy any changed
files after any upgrade. If you don't, your chroot server may be left
vulnerable.Another limitation of chroot jails
is that they aren't impenetrable. Processes run as root from within the jail
can issue the chroot() call to return to the real root
directory. (It's actually a bit more complex than issuing a single chroot() call,
but not by much.) Thus, you should be very cautious about giving root privileges to any server run from within a chroot jail. Although
servers are supposed to be well behaved, bugs
and misconfigurations have been known to provide root access to
undesirable outsiders in the past, and this is all but certain to happen in the
future. Thus, although a chroot jail is a useful security tool, it's not a panacea.A chroot jail can provide
protection against attacks on your computer, but if a miscreant uses a server
to attack other systems, a chroot jail provides little or no protection. For instance, a compromised
DNS server may give false name lookups, allowing an attacker to access an NFS
server that authorizes hosts by name rather than by IP address, even if the DNS
server runs in a chroot jail. Similarly, a server run from a chroot jail might provide
an attacker with a means to directly attack other systems from your server's IP
address.Finally, even if you run one server in a chroot jail,
others may not be running in this way, and so may pose a risk. What's more, if
the filesystem areas handled by these servers overlap, it may be possible to
pass files between the chroot server and the conventional server, which might be risky if the
files in question are configuration files or the like.
