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 ..
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.
