Merge branch 'u2_10_12_branch' of git://git.code.sf.net/p/undernet-ircu/ircu2
[ircu2.10.12-pk.git] / doc / readme.chroot
diff --git a/doc/readme.chroot b/doc/readme.chroot
new file mode 100644 (file)
index 0000000..2c42cac
--- /dev/null
@@ -0,0 +1,91 @@
+Using Chroot With IRCD
+
+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.