Annotation of embedaddon/ipsec-tools/src/racoon/doc/README.privsep, revision 1.1.1.1
1.1 misho 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 $
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to README.privsep CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / ipsec-tools / src / racoon / doc