Could you show the output of `ls -ldR /var/lib/neutron/ipsec/<uuid>/var/run/` before the chmod fix? Is there something interesting showing on audit.log?

And who is the owner of /var/lib/neutron/ipsec/<uuid>/var/run/pluto?

I believe this may have been due to the missing vpnaas.filters file/selinux issues that were fixed in: openstack-neutron-2013.2-14.el6ost, but I was not able to reproduce the issue. Setting to MODIFIED so that it can be tested.

[root@puma10 ~(keystone_admin)]# sudo neutron-rootwrap /etc/neutron/rootwrap.conf ip netns exec qrouter-191841cd-e0be-48fa-9da0-2047d418c540 ipsec pluto --ctlbase /var/lib/neutron/ipsec/191841cd-e0be-48fa-9da0-2047d418c540/var/run/pluto --ipsecdir /var/lib/neutron/ipsec/191841cd-e0be-48fa-9da0-2047d418c540/etc --use-netkey --uniqueids --nat_traversal --secretsfile /var/lib/neutron/ipsec/191841cd-e0be-48fa-9da0-2047d418c540/etc/ipsec.secrets --virtual_private %v4:10.35.170.0/24,%v4:10.35.214.0/24
adjusting ipsec.d to /var/lib/neutron/ipsec/191841cd-e0be-48fa-9da0-2047d418c540/etc
pluto: unable to create lock dir: "/var/lib/neutron/ipsec/191841cd-e0be-48fa-9da0-2047d418c540/var/run/pluto": Permission denied
[root@puma10 ~(keystone_admin)]# ls -ldR /var/lib/neutron/ipsec/191841cd-e0be-48fa-9da0-2047d418c540/var/
drwxr-xr-x. 3 neutron neutron 4096 Dec 10 19:59 /var/lib/neutron/ipsec/191841cd-e0be-48fa-9da0-2047d418c540/var/
[root@puma10 ~(keystone_admin)]# ls -ldR /var/lib/neutron/ipsec/191841cd-e0be-48fa-9da0-2047d418c540/var/run
drwxr-xr-x. 2 neutron neutron 4096 Dec 10 19:59 /var/lib/neutron/ipsec/191841cd-e0be-48fa-9da0-2047d418c540/var/run
[root@puma10 ~(keystone_admin)]# sudo neutron-rootwrap /etc/neutron/rootwrap.conf ip netns exec qrouter-191841cd-e0be-48fa-9da0-2047d418c540 mkdir /var/lib/neutron/ipsec/191841cd-e0be-48fa-9da0-2047d418c540/var/run/pluto
/usr/bin/neutron-rootwrap: Unauthorized command: ip netns exec qrouter-191841cd-e0be-48fa-9da0-2047d418c540 mkdir /var/lib/neutron/ipsec/191841cd-e0be-48fa-9da0-2047d418c540/var/run/pluto (no filter matched)
[root@puma10 ~(keystone_admin)]# ll /usr/share/neutron/rootwrap/
total 28
-rw-r--r--. 1 root root  473 Oct 17 17:01 debug.filters
-rw-r--r--. 1 root root 1457 Oct 17 17:01 dhcp.filters
-rw-r--r--. 1 root root  683 Oct 17 17:01 iptables-firewall.filters
-rw-r--r--. 1 root root 1429 Oct 17 17:01 l3.filters
-rw-r--r--. 1 root root  547 Oct 17 17:01 lbaas-haproxy.filters
-rw-r--r--. 1 root root  547 Oct 17 17:01 openvswitch-plugin.filters
-rw-r--r--. 1 root root  346 Oct 17 17:01 vpnaas.filters
[root@puma10 ~(keystone_admin)]# cat /usr/share/neutron/rootwrap/vpnaas.filters 
# neutron-rootwrap command filters for nodes on which neutron is
# expected to control network
#
# This file should be owned by (and only-writeable by) the root user

# format seems to be
# cmd-name: filter-name, raw-command, user, args

[Filters]

ip: IpFilter, ip, root
ip_exec: IpNetnsExecFilter, ip, root
openswan: CommandFilter, ipsec, root
[root@puma10 ~(keystone_admin)]# cat /usr/share/neutron/rootwrap/debug.filters 
# neutron-rootwrap command filters for nodes on which neutron is
# expected to control network
#
# This file should be owned by (and only-writeable by) the root user

# format seems to be
# cmd-name: filter-name, raw-command, user, args

[Filters]

# This is needed because we should ping
# from inside a namespace which requires root
ping: RegExpFilter, ping, root, ping, -w, \d+, -c, \d+, [0-9\.]+
ping6: RegExpFilter, ping6, root, ping6, -w, \d+, -c, \d+, [0-9A-Fa-f:]+
[root@puma10 ~(keystone_admin)]# tail -20 /var/log/neutron/vpn-agent.log 
2013-12-10 19:24:11.958 2446 INFO neutron.openstack.common.rpc.impl_qpid [-] Connected to AMQP server on 10.35.160.29:5672
2013-12-10 19:59:48.777 2446 WARNING neutron.context [-] Arguments dropped when creating context: {'project_id': u'55751e664bb246faa9db5dd79a48d622'}
2013-12-10 19:59:49.920 2446 ERROR neutron.services.vpn.device_drivers.ipsec [-] Failed to enable vpn process on router 191841cd-e0be-48fa-9da0-2047d418c540
2013-12-10 19:59:49.920 2446 TRACE neutron.services.vpn.device_drivers.ipsec Traceback (most recent call last):
2013-12-10 19:59:49.920 2446 TRACE neutron.services.vpn.device_drivers.ipsec   File "/usr/lib/python2.6/site-packages/neutron/services/vpn/device_drivers/ipsec.py", line 241, in enable
2013-12-10 19:59:49.920 2446 TRACE neutron.services.vpn.device_drivers.ipsec     self.start()
2013-12-10 19:59:49.920 2446 TRACE neutron.services.vpn.device_drivers.ipsec   File "/usr/lib/python2.6/site-packages/neutron/services/vpn/device_drivers/ipsec.py", line 382, in start
2013-12-10 19:59:49.920 2446 TRACE neutron.services.vpn.device_drivers.ipsec     '--virtual_private', virtual_private
2013-12-10 19:59:49.920 2446 TRACE neutron.services.vpn.device_drivers.ipsec   File "/usr/lib/python2.6/site-packages/neutron/services/vpn/device_drivers/ipsec.py", line 311, in _execute
2013-12-10 19:59:49.920 2446 TRACE neutron.services.vpn.device_drivers.ipsec     check_exit_code=check_exit_code)
2013-12-10 19:59:49.920 2446 TRACE neutron.services.vpn.device_drivers.ipsec   File "/usr/lib/python2.6/site-packages/neutron/agent/linux/ip_lib.py", line 458, in execute
2013-12-10 19:59:49.920 2446 TRACE neutron.services.vpn.device_drivers.ipsec     check_exit_code=check_exit_code)
2013-12-10 19:59:49.920 2446 TRACE neutron.services.vpn.device_drivers.ipsec   File "/usr/lib/python2.6/site-packages/neutron/agent/linux/utils.py", line 62, in execute
2013-12-10 19:59:49.920 2446 TRACE neutron.services.vpn.device_drivers.ipsec     raise RuntimeError(m)
2013-12-10 19:59:49.920 2446 TRACE neutron.services.vpn.device_drivers.ipsec RuntimeError: 
2013-12-10 19:59:49.920 2446 TRACE neutron.services.vpn.device_drivers.ipsec Command: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qrouter-191841cd-e0be-48fa-9da0-2047d418c540', 'ipsec', 'pluto', '--ctlbase', '/var/lib/neutron/ipsec/191841cd-e0be-48fa-9da0-2047d418c540/var/run/pluto', '--ipsecdir', '/var/lib/neutron/ipsec/191841cd-e0be-48fa-9da0-2047d418c540/etc', '--use-netkey', '--uniqueids', '--nat_traversal', '--secretsfile', '/var/lib/neutron/ipsec/191841cd-e0be-48fa-9da0-2047d418c540/etc/ipsec.secrets', '--virtual_private', '%v4:10.35.170.0/24,%v4:10.35.214.0/24']
2013-12-10 19:59:49.920 2446 TRACE neutron.services.vpn.device_drivers.ipsec Exit code: 10
2013-12-10 19:59:49.920 2446 TRACE neutron.services.vpn.device_drivers.ipsec Stdout: ''
2013-12-10 19:59:49.920 2446 TRACE neutron.services.vpn.device_drivers.ipsec Stderr: 'adjusting ipsec.d to /var/lib/neutron/ipsec/191841cd-e0be-48fa-9da0-2047d418c540/etc\npluto: unable to create lock dir: "/var/lib/neutron/ipsec/191841cd-e0be-48fa-9da0-2047d418c540/var/run/pluto": Permission denied\n'
2013-12-10 19:59:49.920 2446 TRACE neutron.services.vpn.device_drivers.ipsec 
[root@puma10 ~(keystone_admin)]# sudo ip netns exec qrouter-191841cd-e0be-48fa-9da0-2047d418c540 mkdir /var/lib/neutron/ipsec/191841cd-e0be-48fa-9da0-2047d418c540/var/run/pluto
[root@puma10 ~(keystone_admin)]# 
[root@puma10 ~(keystone_admin)]# getenforce 
Permissive
[root@puma10 ~(keystone_admin)]# grep avc /var/log/messages 
Dec 10 16:36:56 puma10 dbus: avc:  received policyload notice (seqno=2)
Dec 10 16:37:02 puma10 dbus: avc:  received policyload notice (seqno=3)
Dec 10 16:37:09 puma10 dbus: avc:  received policyload notice (seqno=4)
Dec 10 16:37:18 puma10 dbus: avc:  received policyload notice (seqno=5)
Dec 10 16:58:31 puma10 dbus: avc:  received policyload notice (seqno=6)
Dec 10 17:00:58 puma10 dbus: avc:  received policyload notice (seqno=7)
Dec 10 17:03:27 puma10 dbus: avc:  received policyload notice (seqno=8)
Dec 10 19:57:53 puma10 dbus: avc:  received setenforce notice (enforcing=0)
[root@puma10 ~(keystone_admin)]#

Rami Vaknin: Could you include something about what your setup looks like, what neutron client commands you are running in sequence to actually generate the errors, packstack answer files, etc.? Just seeing the actual ipsec commands doesn't help me that much to reproduce the issue.

Also "ausearch -i -m avc" output would be helpful. As would what versions of openstack-selinux and openstack-neutron are installed. It's really hard to be able to do the troubleshooting with just a log dump and no context. I'm not yet an expert on the VPNaaS module, so I need a little more help. ;)

The steps I use to enable LBaaS (on the neutron-server+l3 machine):

* Installing an openswan and openstack-neutron-vpn-agent rpms
* append /etc/neutron/neutron.conf, [DEFAULT] section, service_plugins += neutron.services.vpn.plugin.VPNDriverPlugin
* set /etc/neutron/neutron.conf, [service_providers] section, service_provider = VPN:Vpn:neutron.services.vpn.service_drivers.ipsec.IPsecVPNDriver:default
* set /etc/neutron/vpn_agent.ini, [DEFAULT] section, interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
* set /etc/neutron/vpn_agent.ini, [vpnagent] section, vpn_device_driver = neutron.services.vpn.device_drivers.ipsec.OpenSwanDriver
* chkconfig neutron-vpn-agent on
* restart all neutron services

All VPNaaS objects are created via horizon after enabling VPNaaS gui in /etc/openstack-dashboard/local_settings and reloading httpd.

All your requirements are satisfied:
0) packstack --allinone (using answer file, kinda-distributed installation, services+l3 on one machine, dhcp on another machine, and more 2 compute-node machines)
1) Add the vpnaas.filters file to /usr/share/neutron/rootwrap
2) Add l3_agent.ini to the list of config files in /etc/init.d/neutron-vpn-agent
3) Add fwaas_driver.ini to /etc/neutron and set the appropriate fields
4) Add /etc/neutron/fwaas_driver.ini to the config files in /etc/init.d/neutron-l3-agent
5) Add service_plugins = neutron.services.firewall.fwaas_plugin.FirewallPlugin, neutron.services.vpn.plugin.VPNDriverPlugin to /etc/neutron.conf (should be /etc/neutron/neutron.conf)
6) restart all of the neutron services
7) Fix selinux issues (https://bugzilla.redhat.com/show_bug.cgi?id=1039204) with semanage fcontext -a -t neutron_exec_t /usr/bin/neutron-vpn-agent ; restorecon /usr/bin/neutron* (or disable selinux) (running with permissive)
8) Restart all neutron services
9) Create firewall rules, policy, firewall and verify that firewall shows ACTIVE (I wish)


# ausearch -i -m avc
<no matches>
#
# rpm -q openstack-selinux openstack-neutron
openstack-selinux-0.1.3-2.el6ost.noarch
openstack-neutron-2013.2-14.el6ost.noarch
#

I'll be more than happy if you could connect the env (puma10.scl.lab.tlv.redhat.com, answer file on /root/ANSWER_FILE for non-ssh passwords)

Rami: I'm not seeing the instructions anywhere for setting the service_provider= line that you mention above. The only place I've seen it is in this review which hasn't been merged, yet: https://review.openstack.org/#/c/41827/. I'm not sure if it hurts anything or not, just trying to verify all of the settings. Do you know what instructions you found that required that line?

(In reply to Terry Wilson from comment #10)
> Rami: I'm not seeing the instructions anywhere for setting the
> service_provider= line that you mention above. The only place I've seen it
> is in this review which hasn't been merged, yet:
> https://review.openstack.org/#/c/41827/. I'm not sure if it hurts anything
> or not, just trying to verify all of the settings. Do you know what
> instructions you found that required that line?

I couldn't find instructions for vpn configuration, just clues here and there, the service_provider was not in any instructions I could find - I derived that myself by:

$ grep -iR vpn /etc/neutron/neutron.conf 
# Specify service providers (drivers) for advanced services like loadbalancer, VPN, Firewall.
# List of allowed service type include LOADBALANCER, FIREWALL, VPN

then looking for the possible classes in /usr/lib/python2.6/site-packages/neutron/services/vpn/service_drivers/ipsec.py

I see that the patch you pointed out contains:

service_provider=VPN:openswan:neutron.services.vpn.service_drivers.ipsec.IPsecVPNDriver:default

while I'm using it with different service provider name (service_provider=<service_type>:<name>:<driver>[:default]):

service_provider=VPN:Vpn:neutron.services.vpn.service_drivers.ipsec.IPsecVPNDriver:default

So I've tried to use that once with the patch's service provider name and second without the service_provider line at all but unfortunately I got the same results as described in this bug.

Any ideas?

btw, I'm using openswan-2.6.32-27.el6.x86_64, is that the right rpm to use?

Rami: Ok, I just downloaded lon's RHEL 6.5/RHOS 4.0 test image (http://shell.bos.redhat.com/~lhh/install-rhos4.sh). I created the rhel-6.5-vm, launched it, and edited the runonce.sh script, commenting out the RHOS-4.0-beta repo and uncommenting the RHOS 4.0 Poodle.

After running runonce, it does a packstack --allinone and reboot and I had neutron 2013.2-15 with all of the vpn/fw/selinux fixes. I did

yum -y install openstack-neutron-vpn-agent && chkconfig neutron-vpn-agent on

and then edited /etc/neutron/vpn_agent.ini, uncommenting the driver and check_interval options.

I then added

service_plugins = neutron.services.vpn.plugin.VPNDriverPlugin

to neutron.conf and ran openstack-service restart neutron to restart all of the neutron services. After setting up horizon to enable VPN in local_settings.py and restarting httpd, I created each of IKE Policy, IPSec Policy, VPN Service, and IPSec Site Connections and got no errors in the vpn agent log.

(oh, and yum install openswan in there too, of course).

OK. I can verify that it is definitely the privilege de-escalation code in openswan that is causing this issue. In openswan's programs/pluto/plutomain.c:

#ifdef HAVE_LIBCAP_NG
    /* Drop capabilities */
    capng_clear(CAPNG_SELECT_BOTH);
    capng_updatev(CAPNG_ADD, CAPNG_EFFECTIVE|CAPNG_PERMITTED,
            CAP_NET_BIND_SERVICE, CAP_NET_ADMIN, CAP_NET_RAW,
            CAP_IPC_LOCK, -1);
    /* our children must be able to CAP_NET_ADMIN to change routes.
     */
    capng_updatev(CAPNG_ADD, CAPNG_BOUNDING_SET,
            CAP_NET_ADMIN, -1);
    capng_apply(CAPNG_SELECT_BOTH);
#endif

I also verified by running the pluto command in gdb, setting a breakpoint, and inspecting /proc/$PID/status and verifying that the capabilities set were the ones listed in the code. So, as a test I rhpkg cloned openswan, set the HAVE_LIBCAP_NG define = 0 in the spec file, and did an rhpkg scratch-build and installed it. The problem went away. So, since that isn't really a solution, we'll have to come up with something a little more targeted. Adding CAP_DAC_OVERRIDE to the list of capabilities in the openswan code would most likely fix this. I'm not sure there is much we can do on the neutron side.

I have created a bz against openswan and linked it. If we want this fixed for RHOS, we're most likely going to have to ship openswan in our repos with the fix (adding CAP_DAC_OVERRIDE).

In addition, if QE would like to continue testing past this issue, they can install the patched openswan scratch-build that I made that fixes the issue for me:

http://download.devel.redhat.com/brewroot/work/tasks/2739/6722739/openswan-2.6.32-27.el6_5.x86_64.rpm

The patch is very simple:

--- programs/pluto/plutomain.c.bak  2013-12-12 15:06:52.182664449 -0600
+++ programs/pluto/plutomain.c  2013-12-12 15:08:01.229676601 -0600
@@ -359,7 +359,7 @@
    capng_clear(CAPNG_SELECT_BOTH);
    capng_updatev(CAPNG_ADD, CAPNG_EFFECTIVE|CAPNG_PERMITTED,
            CAP_NET_BIND_SERVICE, CAP_NET_ADMIN, CAP_NET_RAW,
-           CAP_IPC_LOCK, -1);
+           CAP_IPC_LOCK, CAP_DAC_OVERRIDE, -1);
    /* our children must be able to CAP_NET_ADMIN to change routes.
     */
    capng_updatev(CAPNG_ADD, CAPNG_BOUNDING_SET,


I can verify that pluto runs successfully and that the site connection leaves status PENDING_CREATE (to DOWN since I don't have the other side wet up). Rami, could you verify that the above openswan package resolves the issue for you as well?

Terry, would an hack such as pre-creating /var/lib/neutron/ipsec/<uuid>/var/run/pluto and chowning it to root work? I suppose that

  setfacl -m d:u:root:rwx /var/lib/neutron/ipsec/<uuid>/var/run

would be a bit less ugly, as it requires less knowledge about openswap internals.

Dan: Since the directories are created at runtime every time you create a new vpn service, we'd have to hack the neutron VPNaaS code to make the call every time it created a directory. It's certainly doable, but really ugly. No chance to pre-create the directories.

It is ugly, but asking openswan to be less secure because the path we pass to it is not owned by its uid, is no very pretty either...

I don't agree that asking openswan to work in a way where root can write to a directory that root should normally be able to write to is "not pretty". It's pretty startling to run across an error where root can't write to a directory (and it not be an SELinux issue). There are many tools available to handle locking down the filesystem, and unilaterally overriding the admin by hardcoding this behavior in openswan seems wrong to me.

I'm not completely against hacking around this with a downstream patch in neutron like you suggest, but I think this should ultimately be fixed in openswan.

*** Bug 1039347 has been marked as a duplicate of this bug. ***

(In reply to Terry Wilson from comment #19)
> In addition, if QE would like to continue testing past this issue, they can
> install the patched openswan scratch-build that I made that fixes the issue
> for me:
> 
> http://download.devel.redhat.com/brewroot/work/tasks/2739/6722739/openswan-2.
> 6.32-27.el6_5.x86_64.rpm

This rpm seems to work, my vpn service is active now.
Moving this bug to Assigned.

> 
> The patch is very simple:
> 
> --- programs/pluto/plutomain.c.bak  2013-12-12 15:06:52.182664449 -0600
> +++ programs/pluto/plutomain.c  2013-12-12 15:08:01.229676601 -0600
> @@ -359,7 +359,7 @@
>     capng_clear(CAPNG_SELECT_BOTH);
>     capng_updatev(CAPNG_ADD, CAPNG_EFFECTIVE|CAPNG_PERMITTED,
>             CAP_NET_BIND_SERVICE, CAP_NET_ADMIN, CAP_NET_RAW,
> -           CAP_IPC_LOCK, -1);
> +           CAP_IPC_LOCK, CAP_DAC_OVERRIDE, -1);
>     /* our children must be able to CAP_NET_ADMIN to change routes.
>      */
>     capng_updatev(CAPNG_ADD, CAPNG_BOUNDING_SET,
> 
> 
> I can verify that pluto runs successfully and that the site connection
> leaves status PENDING_CREATE (to DOWN since I don't have the other side wet
> up). Rami, could you verify that the above openswan package resolves the
> issue for you as well?

Terry, for the record I must admit that I was puzzled by this non-omnipotent-root. However, do you think that creating /var/lib/neutron/ipsec/<uuid>/var/run/pluto/ as root, would solve this from the Neutron side?

diff --git a/etc/neutron/rootwrap.d/vpnaas.filters b/etc/neutron/rootwrap.d/vpnaas.filters
index 7848136..106ce79 100644
--- a/etc/neutron/rootwrap.d/vpnaas.filters
+++ b/etc/neutron/rootwrap.d/vpnaas.filters
@@ -11,3 +11,4 @@
 ip: IpFilter, ip, root
 ip_exec: IpNetnsExecFilter, ip, root
 openswan: CommandFilter, ipsec, root
+mkdir: PathFilter, mkdir, root, /var/lib/neutron/
diff --git a/neutron/services/vpn/device_drivers/ipsec.py b/neutron/services/vpn/device_drivers/ipsec.py
index 1d2d602..7bee34a 100644
--- a/neutron/services/vpn/device_drivers/ipsec.py
+++ b/neutron/services/vpn/device_drivers/ipsec.py
@@ -371,6 +371,7 @@ class OpenSwanProcess(BaseSwanProcess):
         if not self.namespace:
             return
         virtual_private = self._virtual_privates()
+        self._execute(['mkdir', self.pid_path])
         #start pluto IKE keying daemon
         self._execute([self.binary,
                        'pluto',

Dan: It's something that we could try doing in a distro-specific patch as a workaround, but there is no way that they'd accept it upstream since there are multiple *swan packages and the others don't seem to be running into this issue. So this is a case of "well, things work everywhere but on Red Hat". And I really try to stay away from downstream patches if I can get away with it--especially when they feel like hacks.

I'd much rather see CAP_DAC_OVERRIDE added to openswan. Or at the very least something like pseduo code:

if (uid == 0 && owner(ctlbasedir) != 0) {
   add_cap(CAP_DAC_OVERRIDE);
}

That way one only enables it when the user obviously intends it. Or even add a CLI switch or something to make it even more explicit.

I see the same problem with libreswan-2.7-1.fc19.

Dan's patch in comment 28 was not sufficient to work around this issue.

Hi all, I also have the same problem, but the RPM link above is not valid.

http://download.devel.redhat.com/brewroot/work/tasks/2739/6722739/openswan-2.6.32-27.el6_5.x86_64.rpm

Could anyone provide a link to download that RPM package?

Thanks a lot.

I tried to modify plutomain.c code and re-compile openswan, but it seems that the problem is still there.

2014-03-03 13:08:26.681 1475 TRACE neutron.services.vpn.device_drivers.ipsec     raise RuntimeError(m)
2014-03-03 13:08:26.681 1475 TRACE neutron.services.vpn.device_drivers.ipsec RuntimeError: 
2014-03-03 13:08:26.681 1475 TRACE neutron.services.vpn.device_drivers.ipsec Command: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qrouter-d22c58c3-aa2c-469d-8c61-96e80d4492c8', 'ipsec', 'pluto', '--ctlbase', '/var/lib/neutron/ipsec/d22c58c3-aa2c-469d-8c61-96e80d4492c8/var/run/pluto', '--ipsecdir', '/var/lib/neutron/ipsec/d22c58c3-aa2c-469d-8c61-96e80d4492c8/etc', '--use-netkey', '--uniqueids', '--nat_traversal', '--secretsfile', '/var/lib/neutron/ipsec/d22c58c3-aa2c-469d-8c61-96e80d4492c8/etc/ipsec.secrets', '--virtual_private', '%v4:192.168.24.0/24,%v4:192.168.99.0/24']
2014-03-03 13:08:26.681 1475 TRACE neutron.services.vpn.device_drivers.ipsec Exit code: 10
2014-03-03 13:08:26.681 1475 TRACE neutron.services.vpn.device_drivers.ipsec Stdout: ''
2014-03-03 13:08:26.681 1475 TRACE neutron.services.vpn.device_drivers.ipsec Stderr: 'adjusting ipsec.d to /var/lib/neutron/ipsec/d22c58c3-aa2c-469d-8c61-96e80d4492c8/etc\npluto: unable to create lock dir: "/var/lib/neutron/ipsec/d22c58c3-aa2c-469d-8c61-96e80d4492c8/var/run/pluto": Permission denied\n'

Created attachment 878709 [details]
Keep CAP_DAC_OVERRIDE only when necessary

I have verified that my previous patch to openswan still works, but have uploaded to bz 1041576 and here a patch that more specifically targets when to allow CAP_DAC_OVERRIDE.

This patch, instead of unconditionally keeping CAP_DAC_OVERRIDE, instead checks the parent directory of ctlbase for RWX owner/gid perms if running as root and keeps CAP_DAC_OVERRIDE if root is passing in a ctlbase that it wouldn't be able to access after dropping the capability. In this way, only when it is absolutely necessary and obviously the intention of the user running pluto is this capability retained.

As a note, in most normal circumstances I'd never check permissions then try an operation, but as you can't restore capabilities that you've given up and you would need the capability removed to be able to test via creation, I go ahead and do the check. Also, I would have used euidaccess() instead of manually checking the uid/gid permissions, but access/euidaccess code in to return 0 if uid/euid == 0.

CAP_DAC_OVERRIDE means the process cannot be confined and can completely compromise the system. If CAP_DAC_OVERRIDE is required, then don't bother dropping privs at all. IOW, stay root with full privs. Its the same difference.

The correct solution is to use file owner/group permissions to fix the paths in question so that its successful without elevated privs.

(I thought I had answered this already, there might be two bugzillas related to this item)

I've attached a patch that changes the order of creating the socket and of dropping CAP_DAC_OVERRIDE. This allows pluto to still run without CAP_DAC_OVERRIDE. The only requirement of the caller becomes to cleanup the directory containing the socket and pid file, as pluto no longer has the permissions to clean those up at shutdown.

Created attachment 879075 [details]
patch to move CAP_DAC_OVERRIDE drop after we create the socket

This should address your issue.

As this isn't a neutron issue, the status for the issues is tracked in bugs linked here for the openswan/libreswan projects, this is fixed (in openswan) in the release it was reported against (in build openswan-2.6.32-27.4.el6_5), and there is a "Make VPN a supported component" issue, I'm closing this issue.