1 | Using Racoon with Privilege Separation |
---|
2 | Tue Mar 25 16:37:09 MDT 2008 |
---|
3 | |
---|
4 | |
---|
5 | Racoon can run in a chroot'd environment. When so instructed, it runs as two |
---|
6 | processes, one of which handles a small number of simple requests and runs as |
---|
7 | root in the full native filesystem, and another which runs as a less |
---|
8 | privileged user in a chroot'd environment and which handles all the other and |
---|
9 | very complex business of racoon. |
---|
10 | |
---|
11 | Because racoon does many complex things there are many opportunities for |
---|
12 | coding errors to lead to compromises and so this separation is important. If |
---|
13 | someone breaks into your system using racoon and you have enabled privilege |
---|
14 | separation, they will find themselves in a very limited environment and unable |
---|
15 | to do much damage. They may be able to alter the host's security associations |
---|
16 | or obtain the private keys stored on that system using file descriptors |
---|
17 | available to the unprivileged instance of racoon, and from there they will be |
---|
18 | able to alter security associations on other hosts in disruptive or dangerous |
---|
19 | ways if you have generate_policy enabled on those hosts. But that's because |
---|
20 | in its current form generate_policy is itself dangerous and requires that you |
---|
21 | trust anyone with the credentials to use it. |
---|
22 | |
---|
23 | They will also be able to execute any scripts you have placed in the scripts |
---|
24 | directory, although racoon will prevent them from mis-using the traditional |
---|
25 | environment variables PATH, LD_LIBRARY_PATH, and IFS. But if you have |
---|
26 | introduced vulnerabilities into your scripts you may want to re-visit them. |
---|
27 | The thing to watch for is blindly trusting the environment variables passed |
---|
28 | in by racoon - assume they could be set to anything by a malicious entity and |
---|
29 | check them for suitability before using them. |
---|
30 | |
---|
31 | All these possibilities are present when privilege separation is not enabled, |
---|
32 | and they are greatly reduced when it is enabled because the resources |
---|
33 | available to the attacker are less. |
---|
34 | |
---|
35 | ***** |
---|
36 | |
---|
37 | The basic concept with racoon's privilege separation is that a minimal |
---|
38 | environment containing all the files racoon needs to operate - with the |
---|
39 | exception of private keys, scripts, and system-wide authentication services - |
---|
40 | is placed in a stripped-down copy of the original environment. The private |
---|
41 | keys and scripts are left in the original environment where only the |
---|
42 | privileged instance of racoon will have access to them. |
---|
43 | |
---|
44 | Here are basic instructions for setting up racoon to run with privilege |
---|
45 | separation: |
---|
46 | |
---|
47 | |
---|
48 | First, create a user/group for racoon to run under. For example, user:group |
---|
49 | ike:ike. The account should not have a usable password or real home |
---|
50 | directory, so copy the general format of another system-services type account |
---|
51 | such as 'daemon'. |
---|
52 | |
---|
53 | You already have files in, e.g. /usr/local/etc/racoon - perhaps racoon.conf, a |
---|
54 | certs directory containing certificates, a scripts directory, and other |
---|
55 | miscellaneous files such as welcome messages. Perform the following steps: |
---|
56 | |
---|
57 | cd /usr/local/etc/racoon |
---|
58 | mkdir root |
---|
59 | mv certs root |
---|
60 | mkdir certs |
---|
61 | mv root/certs/*.key certs |
---|
62 | |
---|
63 | If you want to be able to switch back and forth between using and not using |
---|
64 | privsep, do this too: |
---|
65 | |
---|
66 | cd /usr/local/etc/racoon/certs |
---|
67 | for i in ../root/certs/* |
---|
68 | do |
---|
69 | ln -s $i . |
---|
70 | done |
---|
71 | |
---|
72 | Now root/certs contains certificates and certs contains the keys. The idea is |
---|
73 | that the public certificates are in the chroot'd area |
---|
74 | (/usr/local/etc/racoon/root) and the keys are available only to the privileged |
---|
75 | instance of racoon. |
---|
76 | |
---|
77 | Move any other racoon configuration data into /usr/local/etc/racoon/root, |
---|
78 | with the exception of the scripts directory and racoon.conf. |
---|
79 | |
---|
80 | All the files in /usr/local/etc/racoon/root should be owned by root and the |
---|
81 | ike:ike user you created should not have write access to any directories or |
---|
82 | files (unless you are using something like 'path backupsa', but you get the |
---|
83 | idea). |
---|
84 | |
---|
85 | Create the device nodes: |
---|
86 | |
---|
87 | mkdir root/dev |
---|
88 | |
---|
89 | Do whatever your OS requires to populate the new dev directory with a |
---|
90 | minimal set of devices, e.g. mknod, MAKEDEV, or mount devfs... In freebsd |
---|
91 | this is done by adding a line to /etc/fstab: |
---|
92 | |
---|
93 | devfs /usr/local/etc/racoon/root/dev devfs rw 0 0 |
---|
94 | |
---|
95 | and then adding a line like this to /etc/rc.conf: |
---|
96 | |
---|
97 | devfs_set_rulesets="/usr/local/etc/racoon/root/dev=devfsrules_basic" |
---|
98 | |
---|
99 | and then adding the following lines to /etc/devfs.rules: |
---|
100 | |
---|
101 | [devfsrules_basic=10] |
---|
102 | add include $devfsrules_hide_all |
---|
103 | add include $devfsrules_unhide_basic |
---|
104 | |
---|
105 | and then either rebooting or entering "mount -a && /etc/rc.d/devfs start". |
---|
106 | |
---|
107 | When done with that: |
---|
108 | |
---|
109 | mkdir -p root/usr/local/etc |
---|
110 | ln -s ../../../ root/usr/local/etc/racoon |
---|
111 | |
---|
112 | This dummy hierarchy keeps the config file consistent between both copies of |
---|
113 | racoon. Of course, you could actually put the certs directory and any other |
---|
114 | configuration data down in the hierarchy but I prefer to leave it at the root |
---|
115 | and link to it as shown. You may end up with something like this: |
---|
116 | |
---|
117 | root# ls -FC /usr/local/etc/racoon/root |
---|
118 | certs/ dev/ usr/ |
---|
119 | |
---|
120 | root# ls -l /usr/local/etc/racoon/root/usr/local/etc |
---|
121 | lrwxr-xr-x 1 root wheel 9 Mar 7 22:13 racoon -> ../../../ |
---|
122 | |
---|
123 | root# ls -FC /usr/local/etc/racoon/root/usr/local/etc/racoon/ |
---|
124 | certs/ dev/ usr/ |
---|
125 | |
---|
126 | Presumably your racoon.conf already contains something like: |
---|
127 | |
---|
128 | path certificate "/usr/local/etc/racoon/certs"; |
---|
129 | path script "/usr/local/etc/racoon/scripts"; |
---|
130 | |
---|
131 | If so, great. If not, add them. Then, finally, add the privsep section: |
---|
132 | |
---|
133 | privsep { |
---|
134 | user "ike"; |
---|
135 | group "ike"; |
---|
136 | chroot "/usr/local/etc/racoon/root"; |
---|
137 | } |
---|
138 | |
---|
139 | Apply the patches posted to the list and rebuild racoon (the patches will be |
---|
140 | incorporated into the release subsequent to the date of this memo, so if you |
---|
141 | use that or a later release you can skip this step). |
---|
142 | |
---|
143 | Restart racoon and hopefully things will work. As of the date of this memo, |
---|
144 | re-loading the configuration file with racoonctl will not work with privsep |
---|
145 | enabled. However, the problem is not insurmountable and if you figure it out |
---|
146 | let us know. |
---|
147 | |
---|
148 | I have not tested privsep with many of racoon's features such as XAUTH or |
---|
149 | scripts, so if you have trouble with them and work anything out please reply |
---|
150 | to the list so that your discoveries may be incorporated into this document. |
---|
151 | |
---|
152 | Last modified: $Date: 2008/03/28 04:18:52 $ |
---|