> Subject: Re: [RFC] vpn: Restrict connman-vpnd capabilities
> From: Patrik.Flykt@linux.intel.com
> To: ajbibb@outlook.com
> CC: connman@lists.01.org
> Date: Wed, 10 Feb 2016 09:48:25 +0200
>
>
> Hi,
>
> On Tue, 2016-02-09 at 19:24 -0500, Andrew Bibb wrote:
>
> > The file pointed to by OpenVPN.ConfigFile has no entry for --tmp-dir,
> > so I tried adding that line with it pointing /var and then /tmp
> > (reboot between) and no luck.
>
> --tmp-dir is better placed in /tmp. Stopping the vpn service and killing
> connman-vpnd should be enough.
>
> > ps axu | grep openvpn returns one line so it appears that the daemon
> > starts.
> >
> > In connmanctl immediately after typing "connect" an error is returned:
> > Error /net/connman/service/SERVICE_NAME: Input/output error
>
> Is connman-vpnd trying to ask input from you? Have a connmanctl running
> with 'vpnagent on' to see if the user is prompted for something.
>
> > I was thinking it was a permissions error which is what led me to the
> > mailing list posting. After trying the --tmp-dir option with no luck
> > I removed the single line:
> >
> > CapabilityBoundingSet=CAP_KILL CAP_NET_ADMIN CAP_NET_BIND_SERVICE
> > CAP_NET_RAW
>
> If this worked, then VPNC started by connman-vpnd needs some extra
> capability. For startes check that the VPNC daemon is capable of writing
> into the temporary directory as it is one possible source of problems
> since the capalities are now limited.
>
> > The ProtectHome and ProtectSystem lines I left in and that combination
> > of lines work. I can make a connection just as it used to.
> >
> >
> > It is very much sounding like it is not a Connman issue, but rather a
> > packaging issue. I can open a bug report on Arch. I also want to see
> > what they did between 1.31-1 and 1-31-2. I upgrade on a weekly basis
> > and completely missed the 1.31-1 release. It must not have been out
> > there for long.
>
> The 1.31-2 does something funny when symlinking /etc/resolv.conf, it
> basically drops the /run direcotory creation. But the previous version,
> if installed, has already created the symlink from /etc/resolv.conf or
> similar. I was unable to quickly figure out whether something else was
> modified, I'm not familiar with Arch Linux packaging.
>
> Cheers,
>
> Patrik
>
To your questions:
I ran connmanctl again (had also done so before) with vpnagent on and no difference.  Connmanctl immediately exits with the Input/output error.  

I checked the change log on Arch and the change between 1.31-1 and 1.31-2 is that they delete /usr/lib/tmpfiles.d/connman/connman_resolveconf.conf after install.  That does not seem right to me, but it is after the install so unless Connman sources that file I suppose it would not make any difference.  The change was made because someone's custom /etc/resolve.conf was being overwritten by Connman.  I also think that is wrong as I though once you installed Connman you were supposed to let Connman deal with all the routing stuff.  I don't believe that is directly related to this problem (but if it is wrong let me know and I'll file a bug report on it) Anyway, I got a copy of 1.31-1, installed it (stopped and started connman-vpn) and no changes.

Lastly I decided to play around with the CapabiliyBoundingSet a bit based on your suggestion.  Adding CAP_DAC_READ_SEARCH to the "as shipped" list will allow OpenVPN to connect.  I never even knew these existed until this evening, and I only picked that one based on reading the manpage, so the probability of it being the proper one is likely not great.  Using CAP_DAC_OVERRIDE also works, but that bypasses write permissions and seems to be overkill.

Andrew