crypto/dist/ipsec-tools/src/racoon/doc/README.privsep

   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 $