IPSec (charon) demon does not reduce privilege after startup

[mikejuni]

IPSec (charon) daemon from strongswan does not reduce privilege from root after startup. It would greatly improve security if this is done and there should not be any harm of doing so.

Currently if you do
ps aux | grep charon
you will see that it is running as root.

[fichtner]

According to the following document, this needs to be compiled into StrongSwan, but I found no such option in the FreeBSD port of StrongSwan.

https://wiki.strongswan.org/projects/strongswan/wiki/ReducedPrivileges
https://github.com/opnsense/ports/blob/master/security/strongswan/Makefile

Am I missing something vital here?

[mikejuni]

You'll probably need to patch the Makefile with --with-capabilities=libcap to enable it. I've it working in FreeBSD before after patching the makefile and building it.

[fichtner]

I'll look into this, although I can't find a libcap on FreeBSD itself. It's in the Linux emulators which we shouldn't touch. Curious how the build goes. Will report back.

[fichtner]

yup:

configure: error: libcap library not found

and this is using "native":

configure: error: capset() not found!

Cheers,
Franco

[mikejuni]

Looks like now FreeBSD does not have the necessary APIs to support this. There is no libcap in both base and ports. This is really a setback as it would greatly reduce attack vector although StrongSwan has a rather nice historical record in terms of patching vulnerabilities.

[mikejuni]

Hi, just re-open it to let you know that I've tested setting user = nobody in /usr/local/etc/strongswan.d/charon.conf and it can drop privilege. I am using plain FreeBSD (may switch to HBSD soon) but I think it would apply here as well.
However, the catch is that this setup would only work if your FBSD / HBSD setup is a pure router setup with a default route pointing to the internet (in a road-warrior setup) because once the daemon dropped privilege, although it can setup ipsec child SA association it cannot add a route properly (you'll see it throwing errors), which I think could potentially be fixed by using scripting hooks in StrongSwan via some sudo work.

[fichtner]

I don't see a path forward here mainly for time constraints. If somebody wants to work on this I'll be glad to review, otherwise I'll keep it closed...