Bugzilla Bug 208196

The default config of strongswan is "too secure".  Without investigation it is
not possible to use a strongswan ipsec setup.  A user might circumvent secure
practices in order to get it to work anyway.

Strongswan is built with custom UID/GID to drop root privileges which is very
good practice but has consequences explained at
http://wiki.strongswan.org/wiki/nonRoot

The result is that the charon/pluto daemons are run with the unprivileged user
who has no permission to modify routing tables (as explained on the wiki page).

As to my knowledge ip (iproute2) has no mechanism yet to grant user rights
(either you are allowed everything or nothing), I suggest following solutions:

a) modify the ebuild to pinpoint the user to the wiki article and let him take
care of the issue him/herself  (a quick fix, but einfo/ewarn message might not
be read in most cases)

b) patch up the _updown script to use "sudo ip" commands and modify
/etc/sudoers in a way that user "ipsec" is allowed to run ip with root
privileges (don't know if this is possible automatically from within ebuilds) 
--  this is the suggested method from the wiki

c) chmod iptables so it runs with SUID flag set

d) tell user to run failed "ip addr .." and "ip route .." commands of _updown
script themselves as root -- this is the way I did since strongswan-4  .. which
is annoying


Best regards,
cmuelle8

ps: some real life messages:

Jan 30 18:31:11 [pluto] "t" #1: initiating Main Mode
Jan 30 18:31:12 [pluto] "t" #1: ignoring Vendor ID payload [KAME/racoon]
                - Last output repeated twice -
Jan 30 18:31:12 [pluto] "t" #1: Peer ID is ID_IPV4_ADDR: 'X.X.X.X'
Jan 30 18:31:12 [pluto] "t" #1: ISAKMP SA established
Jan 30 18:31:12 [pluto] "t" #2: initiating Quick Mode
PSK+ENCRYPT+TUNNEL+PFS+UP+MOBIKE {using isakmp#1}
Jan 30 18:31:12 [pluto] "t" #1: ignoring informational payload, type
IPSEC_INITIAL_CONTACT
Jan 30 18:31:13 [pluto] "t" #2: prepare-client output:
/usr/libexec/ipsec/_updown: `ip route delete X.X.X.X/16 2>&1' failed (RTNETLINK
answers: Operation not permitted)
Jan 30 18:31:13 [pluto] "t" #2: prepare-client command exited with status 2
Jan 30 18:31:13 [pluto] "t" #2: route-client output:
/usr/libexec/ipsec/_updown: addsource `ip addr add X.X.X.X/32 dev eth1' failed
(RTNETLINK answers: Operation not permitted)
Jan 30 18:31:13 [pluto] "t" #2: route-client output:
/usr/libexec/ipsec/_updown: doroute `ip route add X.X.X.X/16 via X.X.X.X dev
eth1  src X.X.X.X table 220' failed (RTNETLINK answers: Operation not
permitted)
Jan 30 18:31:13 [pluto] "t" #2: route-client output: Cannot open
"/proc/sys/net/ipv4/route/flush"
Jan 30 18:31:13 [pluto] "t" #2: sent QI2, IPsec SA established {ESP=>ertzet
<wertwert}




Reproducible: Always

Also the user "ipsec" was set up by the ebuild with an id greater 1000 -
shouldn't it be below thousand.  It's a system group/user and no login should
be needed/possible for it - correct me if I'm wrong.

Furthermore the default permissions/owners of the config files are not good. 
The default is /etc/ipsec.conf owned by root, group root - so mode must be
rw-r--r--  else the ipsec binary won't be able to read it after it dropped
privileges to "ipsec" user.  There is more trouble if somebody is using pre
shared keys and using ipsec.secrets to store the PSK - same applies for this
config file - ipsec binary cannot read the PSK, unless ipsec.secrets is owned
by user "ipsec" or is world readable  (which is what most people will do,
seeing that ipsec.conf is owned by root and 0644).

Please ask questions if I'm too unclear or if it's not comprehendable..


Thanks,
cmuelle8

pylon please advise.

As for the first post's issue,  I'm now successfully using the option b)  -
works like a charme.

in /etc/sudoers I have a line
ipsec   localhost=(root)NOPASSWD: /sbin/ip

and in the _updown script i use commands of the form
sudo ip


.. I have no idea how to squezze this into the ebuilds though ..

pylon please advise.

I do not like to install an application with root-privileges enabled.  I fixed
the ebuild that it tells about the wiki-article and changed the ownership of
/etc/ipsec.conf to the user.

Security-team: I guess we can close this bug.

(In reply to comment #5)
> I do not like to install an application with root-privileges enabled.  I fixed
> the ebuild that it tells about the wiki-article and changed the ownership of
> /etc/ipsec.conf to the user.
> 
> Security-team: I guess we can close this bug.

ack, closing this one without glsa as it's basically a config issue, not a
vulnerability. feel free to reopen if you disagree.