From: Cyrus R. <cr...@gm...> - 2008-03-06 00:38:47
Attachments:
patch-aa
|
Racoon has code to run in a chroot'd environment and only handle a limited set of actions in the broader filesystem as root. All things considered, this seems like a pretty good idea. The following contains a patch to: Cause the privileged side to exit when the non-privileged side terminates. Write the pid file out in the correct location relative to the true root, not in the chroot'd environment. I have tested the patch and it worked for me but you should inspect it yourself. I will also describe the steps I took to enable this functionality. **** First, create a user/group for racoon to run under. For example, user:group ike:ike. You already have files in, e.g. /usr/local/etc/racoon - perhaps racoon.conf, a certs directory containing certificates, and a scripts directory. Perform the following steps: cd /usr/local/etc/racoon mkdir root mv certs root mkdir certs mv root/certs/*.key certs Now root/certs contains certificates and certs contains the keys. mkdir root/dev Do whatever your OS requires to populate the new dev directory with a minimal set of devices, e.g. mknod, MAKDEV, or mount devfs... When done with that: mkdir -p root/usr/local/etc/racoon ln -s ../../../../certs root/usr/local/etc/racoon/certs This dummy hierarchy keeps the config file consistent between both copies of racoon. Of course, you could actually put the certs file down in the hierarchy but I prefer to leave it at the root and link to it as shown. 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"; } Restart racoon after applying the patches and rebuilding, and hopefully things will work. |
From: <ma...@ne...> - 2008-03-06 04:30:50
|
Cyrus Rahman <cr...@gm...> wrote: > Racoon has code to run in a chroot'd environment and only handle a > limited set of actions in the broader filesystem as root. All things > considered, this seems like a pretty good idea. The following > contains a patch to: > > Cause the privileged side to exit when the non-privileged side terminates. > Write the pid file out in the correct location relative to the true > root, not in the chroot'd environment. I committed it to HEAD. > I will also describe the steps I took to enable this functionality. What about contributing ipsec-tools/src/racoon/doc/README.privsep? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz ma...@ne... |
From: Cyrus R. <cr...@gm...> - 2008-03-06 05:23:46
|
> > Racoon has code to run in a chroot'd environment and only handle a > > limited set of actions in the broader filesystem as root. All things > > considered, this seems like a pretty good idea. The following > > contains a patch to: > > > > Cause the privileged side to exit when the non-privileged side terminates. > > Write the pid file out in the correct location relative to the true > > root, not in the chroot'd environment. > > I committed it to HEAD. > > > I will also describe the steps I took to enable this functionality. > > What about contributing ipsec-tools/src/racoon/doc/README.privsep? I would love to do that - how about if people provide a little feedback about what is or isn't clear in the short instructions I provided, and based upon those comments I'll produce a better version for the README? |
From: Cyrus R. <cr...@gm...> - 2008-03-08 06:38:32
Attachments:
README-privsep
|
> > What about contributing ipsec-tools/src/racoon/doc/README.privsep? I have worked up a README.privsep document and attached it to this note. Please post any corrections or enhancements to the list! |
From: Cyrus R. <cr...@gm...> - 2008-03-27 03:42:22
Attachments:
ipsec-tools_privsep.patch
|
I've completed the changes to racoon to make privsep work without trouble in my installation. Attached is a patch relative to HEAD. To summarize: The patches contain additonal code to support creation, binding, and setsockopt() modification of the isakmp socket. This is needed because the socket must be re-created when peers go down or when network interfaces bounce. While it is obvious why bind() and setsockopt() must be performed by a privileged process, socket() needs to be performed by the privileged process as well because BSD systems treat sockets created by the superuser specially, and in particular will not honor setsockopt(IP_IPSEC_POLICY) operations, even if successfully performed by the superuser, on sockets not created by the superuser. Without these patches a privsep-running racoon will be unable to bypass IPSEC on the isakmp socket and will fail to negotiate new assocations. I have added checks to the privileged code to ensure that the socket(), bind(), and setsockopt() operations are restricted to those needed by racoon. The code should be portable to the desired targets, but I have only tested it on FreeBSD, where it is working well. Please contact me if you have any questions or problems. |
From: <ma...@ne...> - 2008-03-27 06:52:26
|
Cyrus Rahman <cr...@gm...> wrote: > I've completed the changes to racoon to make privsep work without > trouble in my installation. Attached is a patch relative to HEAD. The looks nice, I just have two minor concerns: 1) style try to avoid lines longer than 80 chars, as it makes troublesome to echange patches through e-mails and to read code on a 80-char large terminal. 2) privsep_compat.c: That kind of stuff seems quite bad on the performance front: int privsep_bind(s, addr, addrlen) int s; const struct sockaddr *addr; socklen_t addrlen; { return bind(s, addr, addrlen); } What about somethign like this? I suspect it will also speed up the build, as it completely removes the needs for compat_privsep.c #ifdef RACOON_PRIVSEP #define PRIVSEP_BIND privsep_bind #else #define PRIVSEP_BIND bind #endif -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz ma...@ne... |