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