Return to README.privsep CVS log

Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / ipsec-tools / src / racoon / doc

ipsec-tools

    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: 2012/02/21 22:39:10 $