Secretagent: New page: ==Introduction== Many system administrators like to run certain daemons within a "jail," a secure area of the file system that the daemon supposedly cannot break out of. That way, if the...

2008-04-25T03:34:44Z

New page: ==Introduction== Many system administrators like to run certain daemons within a "jail," a secure area of the file system that the daemon supposedly cannot break out of. That way, if the...

New page

==Introduction==

Many system administrators like to run certain daemons within a
"jail," a secure area of the file system that the daemon supposedly
cannot break out of. That way, if the daemon is compromised somehow,
the attacker cannot get out and affect the rest of the system in any
way. There are problems with this--the standard UNIX way of doing
this is with the chroot() call, which has been deprecated by the
UNIX98 standard. Moreover, if an attacker has root within the jail,
it is trivial to get *out* of the jail in most circumstances.
Nevertheless, it is still often a good idea, and some systems can use
more secure jails than other systems.

Older versions of ircd supported chroot() operation within the server
itself, but these were fraught with problems--chroot() can only be
called by a process running as root, so ircd had to be started as
root, typically by making it setuid, and would then have to drop those
privileges after calling chroot(). Moreover, the design of the server
would require that the server binary be in DPATH, or the /RESTART
command would not work. In fact, /RESTART still wouldn't work,
because the server would then attempt to change directories to a DPATH
relative to the current root directory--and of course, the root
directory often would not contain the shared libraries necessary for
the ircd to even start.

==Configuring the Server For Use With Chroot==

In the versions of ircd starting with u2.10.11, all the setuid and
chroot() code has been removed from the server. It is still possible
to cause the daemon to run in a chroot() jail, however, through the
use of a wrapper script. This requires making all paths compiled in
to the server be relative to the new root directory; fortunately, this
can be done by giving the configure script the --with-chroot=<dir>
option. The <dir> argument specifies to configure where the root
directory will be, and the server restart path, data path,
configuration file, and debug log files will all be modified to be
relative to this root directory. If the data path or configuration
files cannot be made relative to the specified root directory,
configure will issue an error message and exit; if the server restart
path is not relative to the specified root directory, configure will
issue a warning.

The various paths are made relative to the root directory through the
use of simple edits to their string representation. As an example,
assume that we will be using the root directory "/home/ircd"; if the
data path is "/home/ircd/lib," the data path that will be compiled
into the server will be simply "/lib"; if, on the other hand, the
specified data path were "/usr/local/lib/ircd," configure would issue
an error, since there is no way to make the data path relative to the
specified root directory.

==Preparing the Root Directory==

Most modern operating systems use shared libraries. When using
chroot(), these libraries are searched for relative to the new root
directory, and they must be present in order for a program to
execute. The root directory must be prepared, therefore, by coping
these libraries into the correct place. A script for this purpose has
been provided in tools/mkchroot. This script relies on the command
"ldd," which is used to report which shared libraries are used by a
particular program; it also relies on ldd printing out the full path
to those libraries. If either of these conditions is not met, it will
be necessary to track down the libraries by hand and place them into
the appropriate locations. The tools/mkchroot script takes as its
first argument the path to the directory to be prepared as a root
directory; following this argument should be a list of programs that
will be running with that directory as the root directory.

==Using the Wrapper==

Also provided in the tools subdirectory are the sources for a simple
wrapper program that can be used to start ircd. The program can be
compiled by executing "cc -o wrapper tools/wrapper.c"; it must be run
as root, but do not install it as root, since that would be a major
security risk. This tool can be used to set the hard limit on file
descriptors, as well as a root directory, and so may be useful to the
administrator even if chroot() operation is not desired. A summary of
the command line options for the wrapper tool can be obtained with the
"-h" option. To set the file descriptor limit, use the "-l" option
followed by the desired number of file descriptors; to select an
alternative root directory, use "-c" followed by the desired root
directory. You must use the "-u" option to specify a user name (or
user ID) that the command should be run as; otherwise, the command
will be run as root, which is not what you want (and why you should
never install this program setuid root). Follow the command line
arguments with "--" and the full path to the command that you wish to
run, along with arguments to that command. The "--" tells the wrapper
program to stop interpreting options, and is very important if you
must give the command any options.

[[Category:Technical]]

Using Chroot With IRCD - Revision history

Secretagent: New page: ==Introduction== Many system administrators like to run certain daemons within a "jail," a secure area of the file system that the daemon supposedly cannot break out of. That way, if the...