8:32 a.m.
Have systemd set /home and /run/users read only as VPN certificates can
be stored also in these directories. Protect other directories in the
system by making also them read only. The directory options affect also
all VPN applications started by connman-vpnd.
Restrict capabilities to a subset necessary for normal operations.
---
ProtectSystem=full means the VPN applications cannot write anything to
/usr or /etc. Let's hope this works out for all VPN daemons.
Please test,
Patrik
vpn/connman-vpn.service.in | 3 +++
1 file changed, 3 insertions(+)
diff --git a/vpn/connman-vpn.service.in b/vpn/connman-vpn.service.in
index 120245e..e98fb71 100644
--- a/vpn/connman-vpn.service.in
+++ b/vpn/connman-vpn.service.in
@@ -6,6 +6,9 @@ Type=dbus
BusName=net.connman.vpn
ExecStart=@sbindir@/connman-vpnd -n
StandardOutput=null
+CapabilityBoundingSet=CAP_KILL CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW
+ProtectHome=read-only
+ProtectSystem=full
[Install]
WantedBy=multi-user.target
--
2.1.4
2:42 p.m.
On Tue, 2015-12-01 at 15:32 +0200, Patrik Flykt wrote:
Have systemd set /home and /run/users read only as VPN certificates
can
be stored also in these directories. Protect other directories in the
system by making also them read only. The directory options affect also
all VPN applications started by connman-vpnd.
Restrict capabilities to a subset necessary for normal operations.
Applied, works at least for me with openconnect.
Patrik
10:51 a.m.
I'm sorry about being late to the party, but now that 1.31 is out I've
discovered that this change seems to make OpenVPN not work. I had an
OpenVPN config file that works fine in 1.30 but not 1.31. Removing the
ProtectHome and ProtectSystem lines from the .service file allows
OpenVPN to work in 1.31.
I also have a functional PPTP config file and that works in both 1.30
and 1.31 without modification.
Thanks
Andrew
On 12/1/2015 8:32 AM, Patrik Flykt wrote:
Have systemd set /home and /run/users read only as VPN certificates
can
be stored also in these directories. Protect other directories in the
system by making also them read only. The directory options affect also
all VPN applications started by connman-vpnd.
Restrict capabilities to a subset necessary for normal operations.
---
ProtectSystem=full means the VPN applications cannot write anything to
/usr or /etc. Let's hope this works out for all VPN daemons.
Please test,
Patrik
vpn/connman-vpn.service.in | 3 +++
1 file changed, 3 insertions(+)
diff --git a/vpn/connman-vpn.service.in b/vpn/connman-vpn.service.in
index 120245e..e98fb71 100644
--- a/vpn/connman-vpn.service.in
+++ b/vpn/connman-vpn.service.in
@@ -6,6 +6,9 @@ Type=dbus
BusName=net.connman.vpn
ExecStart=@sbindir@/connman-vpnd -n
StandardOutput=null
+CapabilityBoundingSet=CAP_KILL CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW
+ProtectHome=read-only
+ProtectSystem=full
[Install]
WantedBy=multi-user.target
1:26 p.m.
Actually need to remove all three lines, not just the two I mentioned.
I reverted the file back to the way it was in 1.30, and I initially
thought it was only the two lines that were different.
Sorry about the initial misinformation.
-
Andrew
On 2/7/2016 10:51 AM, Andrew Bibb wrote:
I'm sorry about being late to the party, but now that 1.31 is out
I've
discovered that this change seems to make OpenVPN not work. I had an
OpenVPN config file that works fine in 1.30 but not 1.31. Removing the
ProtectHome and ProtectSystem lines from the .service file allows
OpenVPN to work in 1.31.
I also have a functional PPTP config file and that works in both 1.30
and 1.31 without modification.
Thanks
Andrew
On 12/1/2015 8:32 AM, Patrik Flykt wrote:
> Have systemd set /home and /run/users read only as VPN certificates can
> be stored also in these directories. Protect other directories in the
> system by making also them read only. The directory options affect also
> all VPN applications started by connman-vpnd.
>
> Restrict capabilities to a subset necessary for normal operations.
> ---
>
> ProtectSystem=full means the VPN applications cannot write anything to
> /usr or /etc. Let's hope this works out for all VPN daemons.
>
> Please test,
>
> Patrik
>
>
> vpn/connman-vpn.service.in | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/vpn/connman-vpn.service.in b/vpn/connman-vpn.service.in
> index 120245e..e98fb71 100644
> --- a/vpn/connman-vpn.service.in
> +++ b/vpn/connman-vpn.service.in
> @@ -6,6 +6,9 @@ Type=dbus
> BusName=net.connman.vpn
> ExecStart=@sbindir@/connman-vpnd -n
> StandardOutput=null
> +CapabilityBoundingSet=CAP_KILL CAP_NET_ADMIN CAP_NET_BIND_SERVICE
> CAP_NET_RAW
> +ProtectHome=read-only
> +ProtectSystem=full
> [Install]
> WantedBy=multi-user.target
_______________________________________________
connman mailing list
connman(a)lists.01.org
https://lists.01.org/mailman/listinfo/connman
4:08 a.m.
Hi,
On Sun, 2016-02-07 at 13:26 -0500, Andrew Bibb wrote:
Actually need to remove all three lines, not just the two I
mentioned.
I reverted the file back to the way it was in 1.30, and I initially
thought it was only the two lines that were different.
Sorry about the initial misinformation.
-
Andrew
On 2/7/2016 10:51 AM, Andrew Bibb wrote:
> I'm sorry about being late to the party, but now that 1.31 is out I've
> discovered that this change seems to make OpenVPN not work. I had an
> OpenVPN config file that works fine in 1.30 but not 1.31. Removing the
> ProtectHome and ProtectSystem lines from the .service file allows
> OpenVPN to work in 1.31.
>
> I also have a functional PPTP config file and that works in both 1.30
> and 1.31 without modification.
>
> Thanks
> Andrew
>
> On 12/1/2015 8:32 AM, Patrik Flykt wrote:
>> Have systemd set /home and /run/users read only as VPN certificates can
>> be stored also in these directories. Protect other directories in the
>> system by making also them read only. The directory options affect also
>> all VPN applications started by connman-vpnd.
>>
>> Restrict capabilities to a subset necessary for normal operations.
>> ---
>>
>> ProtectSystem=full means the VPN applications cannot write anything to
>> /usr or /etc. Let's hope this works out for all VPN daemons.
>>
>> Please test,
>>
>> Patrik
>>
>>
>> vpn/connman-vpn.service.in | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/vpn/connman-vpn.service.in b/vpn/connman-vpn.service.in
>> index 120245e..e98fb71 100644
>> --- a/vpn/connman-vpn.service.in
>> +++ b/vpn/connman-vpn.service.in
>> @@ -6,6 +6,9 @@ Type=dbus
>> BusName=net.connman.vpn
>> ExecStart=@sbindir@/connman-vpnd -n
>> StandardOutput=null
>> +CapabilityBoundingSet=CAP_KILL CAP_NET_ADMIN CAP_NET_BIND_SERVICE
>> CAP_NET_RAW
>> +ProtectHome=read-only
>> +ProtectSystem=full
Where does your openvpn instance store its config? Where does it write
its temporary files? A decently configured system should only write
to /var/, as by definition all the other locations should be read-only.
There should not be anything a system wide daemon needs from /home/
either.
Might it be that the capabilities were causing this?
Cheers,
Patrik
8:19 p.m.
On 2/8/2016 4:08 AM, Patrik Flykt wrote:
Hi,
On Sun, 2016-02-07 at 13:26 -0500, Andrew Bibb wrote:
> Actually need to remove all three lines, not just the two I mentioned.
> I reverted the file back to the way it was in 1.30, and I initially
> thought it was only the two lines that were different.
>
> Sorry about the initial misinformation.
>
> -
> Andrew
>
> On 2/7/2016 10:51 AM, Andrew Bibb wrote:
>> I'm sorry about being late to the party, but now that 1.31 is out I've
>> discovered that this change seems to make OpenVPN not work. I had an
>> OpenVPN config file that works fine in 1.30 but not 1.31. Removing the
>> ProtectHome and ProtectSystem lines from the .service file allows
>> OpenVPN to work in 1.31.
>>
>> I also have a functional PPTP config file and that works in both 1.30
>> and 1.31 without modification.
>>
>> Thanks
>> Andrew
>>
>> On 12/1/2015 8:32 AM, Patrik Flykt wrote:
>>> Have systemd set /home and /run/users read only as VPN certificates can
>>> be stored also in these directories. Protect other directories in the
>>> system by making also them read only. The directory options affect also
>>> all VPN applications started by connman-vpnd.
>>>
>>> Restrict capabilities to a subset necessary for normal operations.
>>> ---
>>>
>>> ProtectSystem=full means the VPN applications cannot write anything to
>>> /usr or /etc. Let's hope this works out for all VPN daemons.
>>>
>>> Please test,
>>>
>>> Patrik
>>>
>>>
>>> vpn/connman-vpn.service.in | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/vpn/connman-vpn.service.in b/vpn/connman-vpn.service.in
>>> index 120245e..e98fb71 100644
>>> --- a/vpn/connman-vpn.service.in
>>> +++ b/vpn/connman-vpn.service.in
>>> @@ -6,6 +6,9 @@ Type=dbus
>>> BusName=net.connman.vpn
>>> ExecStart=@sbindir@/connman-vpnd -n
>>> StandardOutput=null
>>> +CapabilityBoundingSet=CAP_KILL CAP_NET_ADMIN CAP_NET_BIND_SERVICE
>>> CAP_NET_RAW
>>> +ProtectHome=read-only
>>> +ProtectSystem=full
Where does your openvpn instance store its config? Where does it write
its temporary files? A decently configured system should only write
to /var/, as by definition all the other locations should be read-only.
There should not be anything a system wide daemon needs from /home/
either.
Might it be that the capabilities were causing this?
Cheers,
Patrik
Pretty much everything is in ~/.local/share. OpenVNP.CACert,
OpenVPN.Cert, OpenVPN.Key, OpenVPN.ConfigFile and OpenVPN.AuthUserPass
in the Connman provisioning file all point to files which live in a
sub-directory inside ~/.local/share. I'm trying to find where it puts
temporary files, but not having a lot of luck so far. I'm using a
stock Arch Linux install with no other modifications.
From your response it sounds as if putting all these in ~/.local/share
is not correct. I was doing that because the VPN connection is only for
me, no one else.
2:01 a.m.
Hi,
On Mon, 2016-02-08 at 20:19 -0500, Andrew Bibb wrote:
Pretty much everything is in ~/.local/share. OpenVNP.CACert,
OpenVPN.Cert, OpenVPN.Key, OpenVPN.ConfigFile and OpenVPN.AuthUserPass
in the Connman provisioning file all point to files which live in a
sub-directory inside ~/.local/share. I'm trying to find where it puts
temporary files, but not having a lot of luck so far. I'm using a
stock Arch Linux install with no other modifications.
From your response it sounds as if putting all these in ~/.local/share
is not correct. I was doing that because the VPN connection is only for
me, no one else.
Reading stuff from ~/.local/share is ok. And works with the current
systemd .service file. I also have certs stored in ~/ and it works fine
here.
Writing temporary and other stuff should go somewhere else, as an
unmodified connman-vpnd will behave as running system-wide. Probably
openvpn tries to write somewhere else than /var, which is prevented
for /home by ProtectHome=read-only and /usr and /etc by
ProtectSystem=full.
Does the openvpn daemon start (ps axu | grep openvpn) ? Does the
OpenVPN.ConfigFile point temporary or other configuration directories
somewhere else than /var ?
Somewhere else someone said that between Arch Linux 1.31-1 and 1.31-2
modifications were made and /var/run/connman/resolv.conf stopped
working. So at least something with the Arch packaging has changed.
Cheers,
Patrik
7:24 p.m.
Subject: Re: [RFC] vpn: Restrict connman-vpnd capabilities
From: Patrik.Flykt(a)linux.intel.com
To: ajbibb(a)outlook.com
CC: connman(a)lists.01.org
Date: Tue, 9 Feb 2016 09:01:28 +0200
Hi,
On Mon, 2016-02-08 at 20:19 -0500, Andrew Bibb wrote:
> Pretty much everything is in ~/.local/share. OpenVNP.CACert,
> OpenVPN.Cert, OpenVPN.Key, OpenVPN.ConfigFile and OpenVPN.AuthUserPass
> in the Connman provisioning file all point to files which live in a
> sub-directory inside ~/.local/share. I'm trying to find where it puts
> temporary files, but not having a lot of luck so far. I'm using a
> stock Arch Linux install with no other modifications.
>
> From your response it sounds as if putting all these in ~/.local/share
> is not correct. I was doing that because the VPN connection is only for
> me, no one else.
Reading stuff from ~/.local/share is ok. And works with the current
systemd .service file. I also have certs stored in ~/ and it works fine
here.
Writing temporary and other stuff should go somewhere else, as an
unmodified connman-vpnd will behave as running system-wide. Probably
openvpn tries to write somewhere else than /var, which is prevented
for /home by ProtectHome=read-only and /usr and /etc by
ProtectSystem=full.
Does the openvpn daemon start (ps axu | grep openvpn) ? Does the
OpenVPN.ConfigFile point temporary or other configuration directories
somewhere else than /var ?
Somewhere else someone said that between Arch Linux 1.31-1 and 1.31-2
modifications were made and /var/run/connman/resolv.conf stopped
working. So at least something with the Arch packaging has changed.
Cheers,
Patrik
Patrik,
Thank you for all the pointers and time.
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.
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
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
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.
Andrew
2:48 a.m.
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
7:30 p.m.
Subject: Re: [RFC] vpn: Restrict connman-vpnd capabilities
From: Patrik.Flykt(a)linux.intel.com
To: ajbibb(a)outlook.com
CC: connman(a)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
4:29 a.m.
Hi,
The below reply got stuck somewhere, I thought it had already been sent
to the mailing list...
On Wed, 2016-02-10 at 19:30 -0500, Andrew Bibb wrote:
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.
man paget says about CAP_DAC_READ_SEARCH that it:
* Bypass file read permission checks and directory read and execute
permission checks;
* Invoke open_by_handle_at(2).
Could it be that openvpn does not have read permissions to the config
file and/or path written to by ConnMan?
Cheers,
Patrik
7:08 p.m.
Subject: Re: [RFC] vpn: Restrict connman-vpnd capabilities
From: Patrik.Flykt(a)linux.intel.com
To: ajbibb(a)outlook.com
CC: connman(a)lists.01.org
Date: Fri, 19 Feb 2016 11:29:22 +0200
Hi,
The below reply got stuck somewhere, I thought it had already been sent
to the mailing list...
On Wed, 2016-02-10 at 19:30 -0500, Andrew Bibb wrote:
> 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.
man paget says about CAP_DAC_READ_SEARCH that it:
* Bypass file read permission checks and directory read and execute
permission checks;
* Invoke open_by_handle_at(2).
Could it be that openvpn does not have read permissions to the config
file and/or path written to by ConnMan?
Cheers,
Patrik
Patrik,
You nailed it, permissions on my personal home directory were 700, so OpenVPN could never
get into ~/.local/share. Change that one to 711 and Connman with OpenVPN will connect
fine (using the default "as shipped" /usr/lib/systemd/system/connman-vpn.service
file).
Thank you for all your help.
Andrew
2:32 a.m.
On Fri, 2016-02-19 at 19:08 -0500, Andrew Bibb wrote:
You nailed it, permissions on my personal home directory were 700,
so
OpenVPN could never get into ~/.local/share. Change that one to 711
and Connman with OpenVPN will connect fine (using the default "as
shipped" /usr/lib/systemd/system/connman-vpn.service file).
Good that it works out of the box! Thanks for taking time figuring this
one out.
Cheers,
Patrik
1712
days inactive
1795
days old
12 comments
3 participants
participants (3)
-
Andrew Bibb -
Patrik Flykt -
Patrik Flykt