Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#792653: Probably related to CapabilityBoundingSet

57 views
Skip to first unread message

Jim Barber

unread,
Feb 19, 2016, 7:20:03 PM2/19/16
to
Alberto Gonzalez wrote:

> Hi,

Hi Alberto.
I only just noticed now that you updated this case.

> Did you run "systemctl daemon-reload" after changing the .service file?

Yes, as per my original bug report I tried the following:

<quote>
Each time I edited the file, I tried the following commands before
starting the service:

systemctl reenable openvpn@.service
systemctl daemon-reload
systemctl daemon-reexec
</quote>

> I'll upload 2.3.10 soon, can you check if it works with it?

I now have the new version of openvpn.
If I re-add the following directives to my configuation with this version, openvpn now starts without error:

user openvpn
group nogroup
iproute /usr/local/sbin/openvpn-ip

And a ps listing shows the openvpn processes running as the openvpn user.

With my phone I am able to connect to openvpn okay, but I was unable to browse anything with my web browser.
If I remove the directives and restart openvpn and reconnect my phone again then browsing works.

So I am now futher than I was before but something else is wrong.

I compared the syslog entries for my connection when running openvpn at the root and openvpn users.
I then compared routes.
When running with the root user, an extra route is added when my phone connects.
When running with the openvpn user, there is no extra route added when my phone connects.

I edited the /usr/local/sbin/openvpn-ip script so that it looks like this:

#!/bin/sh
echo "openvpn-ip script invoked" >> /tmp/openvpn-ip.tmp
/usr/bin/sudo /sbin/ip $*

Then I connected with the phone while openvpn was running as the openvpn user.
The /tmp/openvpn-ip.tmp file was not created.
So it looks like the following directive in the configuration file is not having an effect, or for some reason openvpn is unable to run it:

iproute /usr/local/sbin/openvpn-ip

The permissions on the file are okay and the openvpn user is able to reach it:

# sudo -u openvpn ls -l /usr/local/sbin/openvpn-ip
-rwxr-xr-x 1 root staff 92 Feb 20 07:32 /usr/local/sbin/openvpn-ip

So perhaps another capability is stopping this file from being run?
I saw no other log messages relating to failure to access or run the /usr/local/sbin/openvpn-ip script anywhere.

Regards,
Jim.

Alberto Gonzalez Iniesta

unread,
May 10, 2016, 12:50:04 PM5/10/16
to
On Fri, Feb 19, 2016 at 11:56:10PM +0000, Jim Barber wrote:
>
> So perhaps another capability is stopping this file from being run?
> I saw no other log messages relating to failure to access or run the /usr/local/sbin/openvpn-ip script anywhere.

Hi Jim,

So sorry took me this long to answer. I'm pretty sure this is related to
capabilities. Could try copying /lib/systemd/system/openvpn@.service to
/etc/systemd/system/openvpn@.service and removin the
CapabilityBoundingSet line from it?

Thanks,

Alberto

--
Alberto Gonzalez Iniesta | Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred | http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55

Alberto Gonzalez Iniesta

unread,
May 10, 2016, 1:00:04 PM5/10/16
to
On Tue, May 10, 2016 at 12:53:17PM -0400, Simon Deziel wrote:
> Hi Alberto and Jim,
>
> On 2016-05-10 12:45 PM, Alberto Gonzalez Iniesta wrote:
> > So sorry took me this long to answer. I'm pretty sure this is related to
> > capabilities. Could try copying /lib/systemd/system/openvpn@.service to
> > /etc/systemd/system/openvpn@.service and removin the
> > CapabilityBoundingSet line from it?
>
> Systemd provides a nice command for just this:
>
> systemctl edit openvpn@.service
>
> This will run $EDITOR and you'll be able to override just the part that
> you need. In Jim's case, setting CapabilityBoundingSet to be empty
> should do it:
>
> [Service]
> CapabilityBoundingSet=
>


Nice! Thanks Simon!

Simon Deziel

unread,
May 10, 2016, 1:00:05 PM5/10/16
to
Hi Alberto and Jim,

On 2016-05-10 12:45 PM, Alberto Gonzalez Iniesta wrote:
> So sorry took me this long to answer. I'm pretty sure this is related to
> capabilities. Could try copying /lib/systemd/system/openvpn@.service to
> /etc/systemd/system/openvpn@.service and removin the
> CapabilityBoundingSet line from it?

Systemd provides a nice command for just this:

systemctl edit openvpn@.service

This will run $EDITOR and you'll be able to override just the part that
you need. In Jim's case, setting CapabilityBoundingSet to be empty
should do it:

[Service]
CapabilityBoundingSet=


HTH,
Simon

BARBER, Jim

unread,
May 13, 2016, 8:40:03 AM5/13/16
to
I tried Simon Deziel's technique first.
I ran: systemctl edit openvpn@.service
It opened a blank editor and I added the following lines:

[Service]
CapabilityBoundingSet=

This created the /etc/systemd/system/openvpn@.service.d/override.conf file with the statements above.
I then ran 'systemctl daemon-reload' to make sure the change is picked up.

I put my OpenVPN config files in place with the following statements in them again:

user openvpn
group nogroup
iproute /usr/local/sbin/openvpn-ip

I tried to start OpenVPN and it failed to start with the following error:

May 13 19:50:02 gecko ovpn-openvpn-udp-1194[22901]: ERROR: Cannot ioctl TUNSETIFF tun0: Operation not permitted (errno=1)
May 13 19:50:02 gecko ovpn-openvpn-udp-1194[22901]: Exiting due to fatal error

It would seem that specifying the CapabilityBoundingSet= line and leaving it empty ends up leaving the program with no capabilities?

So next I tried Alberto's suggestion of copying /lib/systemd/system/openvpn@.service to
/etc/systemd/system/openvpn@.service and I deleted the CapabilityBoundingSet=* line.
I also removed the /etc/systemd/system/openvpn@.service.d/override.conf file I created before.
I then ran 'systemctl daemon-reload' to make sure the change is picked up.

The OpenVPN service ran, but as before, when I connected, no route was added.
My debugging statements in the /usr/local/sbin/openvpn-ip script did not produce anything, so it wasn't invoked.

I backed out all my service changes, put my old OpenVPN configuration in place that has it running as root, and all works as expected when I connect.
So the problem of trying to run OpenVPN as a non-privileged user still persists at this point.

Simon Deziel

unread,
May 13, 2016, 9:10:03 AM5/13/16
to
Hi Jim,

On 2016-05-13 08:19 AM, BARBER, Jim wrote:
> I tried Simon Deziel's technique first.
> I ran: systemctl edit openvpn@.service
> It opened a blank editor and I added the following lines:
>
> [Service]
> CapabilityBoundingSet=

I'm sorry to have induce you in error. Apparently you need to set it
like that to properly under any previous effect:

[Service]
CapabilityBoundingSet=~

This is explained here [1]:

> If set to "~" (without any further argument), the bounding set is
> reset to the full set of available capabilities, also undoing any
> previous settings.

Sorry about the confusion.
Simon

1:
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#CapabilityBoundingSet=

Bernhard Schmidt

unread,
Oct 9, 2017, 4:50:02 PM10/9/17
to
Control: tags -1 wontfix
Control: summary -1 CapabilityBoundingSet prevents "Unprivileged mode", needs override

On Fri, May 13, 2016 at 09:01:20AM -0400, Simon Deziel wrote:

Hi,

> Hi Jim,
>
> On 2016-05-13 08:19 AM, BARBER, Jim wrote:
> > I tried Simon Deziel's technique first.
> > I ran: systemctl edit openvpn@.service
> > It opened a blank editor and I added the following lines:
> >
> > [Service]
> > CapabilityBoundingSet=
>
> I'm sorry to have induce you in error. Apparently you need to set it
> like that to properly under any previous effect:
>
> [Service]
> CapabilityBoundingSet=~
>
> This is explained here [1]:
>
> > If set to "~" (without any further argument), the bounding set is
> > reset to the full set of available capabilities, also undoing any
> > previous settings.

So, as far as I understand this bug the systemd CapabilityBoundingSet
prevents "sudo" from working

I'm marking this as "wontfix" since you can override it locally if
necessary, and the default protection with the capabilities is more
important

Bernhard
0 new messages