Annotation of embedaddon/ipsec-tools/src/racoon/doc/README.privsep, revision 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