doc/readme.chroot

   1 Using Chroot With IRCD
   2
   3 Introduction
   4
   5 Many system administrators like to run certain daemons within a
   6 "jail," a secure area of the file system that the daemon supposedly
   7 cannot break out of.  That way, if the daemon is compromised somehow,
   8 the attacker cannot get out and affect the rest of the system in any
   9 way.  There are problems with this--the standard UNIX way of doing
  10 this is with the chroot() call, which has been deprecated by the
  11 UNIX98 standard.  Moreover, if an attacker has root within the jail,
  12 it is trivial to get *out* of the jail in most circumstances.
  13 Nevertheless, it is still often a good idea, and some systems can use
  14 more secure jails than other systems.
  15
  16 Older versions of ircd supported chroot() operation within the server
  17 itself, but these were fraught with problems--chroot() can only be
  18 called by a process running as root, so ircd had to be started as
  19 root, typically by making it setuid, and would then have to drop those
  20 privileges after calling chroot().  Moreover, the design of the server
  21 would require that the server binary be in DPATH, or the /RESTART
  22 command would not work.  In fact, /RESTART still wouldn't work,
  23 because the server would then attempt to change directories to a DPATH
  24 relative to the current root directory--and of course, the root
  25 directory often would not contain the shared libraries necessary for
  26 the ircd to even start.
  27
  28 Configuring the Server For Use With Chroot
  29
  30 In the versions of ircd starting with u2.10.11, all the setuid and
  31 chroot() code has been removed from the server.  It is still possible
  32 to cause the daemon to run in a chroot() jail, however, through the
  33 use of a wrapper script.  This requires making all paths compiled in
  34 to the server be relative to the new root directory; fortunately, this
  35 can be done by giving the configure script the --with-chroot=<dir>
  36 option.  The <dir> argument specifies to configure where the root
  37 directory will be, and the server restart path, data path,
  38 configuration file, and debug log files will all be modified to be
  39 relative to this root directory.  If the data path or configuration
  40 files cannot be made relative to the specified root directory,
  41 configure will issue an error message and exit; if the server restart
  42 path is not relative to the specified root directory, configure will
  43 issue a warning.
  44
  45 The various paths are made relative to the root directory through the
  46 use of simple edits to their string representation.  As an example,
  47 assume that we will be using the root directory "/home/ircd"; if the
  48 data path is "/home/ircd/lib," the data path that will be compiled
  49 into the server will be simply "/lib"; if, on the other hand, the
  50 specified data path were "/usr/local/lib/ircd," configure would issue
  51 an error, since there is no way to make the data path relative to the
  52 specified root directory.
  53
  54 Preparing the Root Directory
  55
  56 Most modern operating systems use shared libraries.  When using
  57 chroot(), these libraries are searched for relative to the new root
  58 directory, and they must be present in order for a program to
  59 execute.  The root directory must be prepared, therefore, by coping
  60 these libraries into the correct place.  A script for this purpose has
  61 been provided in tools/mkchroot.  This script relies on the command
  62 "ldd," which is used to report which shared libraries are used by a
  63 particular program; it also relies on ldd printing out the full path
  64 to those libraries.  If either of these conditions is not met, it will
  65 be necessary to track down the libraries by hand and place them into
  66 the appropriate locations.  The tools/mkchroot script takes as its
  67 first argument the path to the directory to be prepared as a root
  68 directory; following this argument should be a list of programs that
  69 will be running with that directory as the root directory.
  70
  71 Using the Wrapper
  72
  73 Also provided in the tools subdirectory are the sources for a simple
  74 wrapper program that can be used to start ircd.  The program can be
  75 compiled by executing "cc -o wrapper tools/wrapper.c"; it must be run
  76 as root, but do not install it as root, since that would be a major
  77 security risk.  This tool can be used to set the hard limit on file
  78 descriptors, as well as a root directory, and so may be useful to the
  79 administrator even if chroot() operation is not desired.  A summary of
  80 the command line options for the wrapper tool can be obtained with the
  81 "-h" option.  To set the file descriptor limit, use the "-l" option
  82 followed by the desired number of file descriptors; to select an
  83 alternative root directory, use "-c" followed by the desired root
  84 directory.  You must use the "-u" option to specify a user name (or
  85 user ID) that the command should be run as; otherwise, the command
  86 will be run as root, which is not what you want (and why you should
  87 never install this program setuid root).  Follow the command line
  88 arguments with "--" and the full path to the command that you wish to
  89 run, along with arguments to that command.  The "--" tells the wrapper
  90 program to stop interpreting options, and is very important if you
  91 must give the command any options.