> Subject: Re: [RFC] vpn: Restrict connman-vpnd capabilities > From: Patrik.Flykt@linux.intel.com > To: firstname.lastname@example.org > CC: email@example.com > 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.