1

OS: Debian 11
Package: OpenVPN 2.5.1

Background:

After an update, Openvpn-2.5 clients can no longer use iproute to modify the interface and configure routes pushed by the OpenVPN server after root privileges are dropped and the system unit running as an unprivileged user. Based on discussions in these two threads on the iproute issue:
https://bugs.archlinux.org/task/68480
https://phabricator.vyos.net/T3805

A workaround was suggested to remove user & group directives from /etc/openvpn/openvpn.conf and to add Ambient Capabilities, User=tunnel, Group=tunnel to a separate .service file.

There is already an existing Openvpn service file ([email protected]) in /lib/systemd/system so we created a new directory and included a .service file in it - /lib/systemd/system/[email protected]/override.conf

# separate service file containing User and group directives along with Ambient capabilities

[Service]

User=tunnel
Group=tunnel
SecureBits=keep-caps

ExecStartPre=/usr/bin/sudo --non-interactive /usr/sbin/openvpn --rmtun --dev tun0
ExecStartPre=/usr/bin/sudo --non-interactive /usr/sbin/openvpn --mktun --dev tun0 --dev-type tun --user tunnel --group tunnel
ExecStopPost=/usr/bin/sudo --non-interactive /usr/sbin/openvpn --rmtun --dev tun0

AmbientCapabilities=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE CAP_AUDIT_WRITE

Ran the following commands:

sudo systemctl daemon-reload
sudo chown -R tunnel:tunnel /etc/openvpn /run/openvpn
sudo /usr/sbin/openvpn --rmtun --dev tun0
sudo /usr/sbin/openvpn --mktun --dev tun0 --dev-type tun --user tunnel --group tunnel
cd /etc/openvpn/
sudo -u tunnel openvpn /etc/openvpn/openvpn.conf

Error

The expectation was that the unprivileged User=tunnel will have the ambient capabilities to open up tun0 and modify the interface to complete the openvpn connection. However, it encountered an error.

#Error after running sudo -u tunnel openvpn /etc/openvpn/openvpn.conf

2022-06-24 17:32:08 us=174691 TUN/TAP device tun0 opened
2022-06-24 17:32:08 us=174755 do_ifconfig, ipv4=1, ipv6=0
2022-06-24 17:32:08 us=174844 net_iface_mtu_set: mtu 1500 for tun0
2022-06-24 17:32:08 us=175005 sitnl_send: rtnl: generic error (-1): Operation not permitted
2022-06-24 17:32:08 us=175084 Linux can't set mtu (1500) on tun0
2022-06-24 17:32:08 us=175142 Exiting due to fatal error

The solution that works

However, with capsh, I gave Ambient Capability directly to the Openvpn executable with user=tunnel privileges, and nothing in the systemd service:

sudo /sbin/capsh --keep=1 --user='tunnel' --inh='cap_ipc_lock,cap_net_admin,cap_net_bind_service,cap_net_raw,cap_setgid,cap_setuid,cap_sys_chroot,cap_dac_override,cap_audit_write' --addamb='cap_ipc_lock,cap_net_admin,cap_net_bind_service,cap_net_raw,cap_setgid,cap_setuid,cap_sys_chroot,cap_dac_override,cap_audit_write' -- -c 'openvpn /etc/openvpn/openvpn.conf'

The issue:

Why wasn't systemd able to set the Ambient Capabilities for user=tunnel whereas capsh was able to? How to make this work with systemd?

1 Answer 1

Reset to default
0

I suspect sudo -u tunnel clears ambient capabilities. To confirm, you might try inserting these lines before the last one:

/sbin/capsh --print
sudo -u tunnel /sbin/capsh --print
sudo -u tunnel openvpn /etc/openvpn/openvpn.conf
1
  • sudo -u tunnel /sbin/capsh --print gives Ambient set = I think you may be correct, tunnel loses its Ambient Capabilities.
    – depar
    Jun 25, 2022 at 14:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .