]>
Commit | Line | Data |
---|---|---|
189935b1 | 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. |