Re: [Openvpn-users] --user specified but lacking CAP_SETPCAP

[Gert Doering]

Hi,

On Thu, Oct 26, 2023 at 05:27:30PM +0200, Marc SCHAEFER wrote:
> And, if you run OpenVPN within a Docker container, you will need to manually 
> add
> that capability at the Docker container creation time:
> 
>--cap-add=NET_ADMIN

Ah, yes, thanks for reminding me.

So, systemd with a unit file that takes away too many capabilities, or
docker might be ways to start OpenVPN that will then trigger "does not
work with DCO"...

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] --user specified but lacking CAP_SETPCAP

[Gert Doering]

Hi,

On Thu, Oct 26, 2023 at 10:04:18AM +0200, David Sommerseth wrote:
> When starting OpenVPN via the openvpn-client@.service or
> openvpn-server@.service systemd unit files, some capabilities are granted to
> the the OpenVPN process may transition to, like the "openvpn" user.
> CAP_SETPCAP and CAP_NET_ADMIN are two of those.  The first one is actually
> used to allow the OpenVPN process to keep setup certain capabilities as it
> transitions to the user provided via the --user option.  The CAP_NET_ADMIN
> is, not surprisingly, used to setup the virtual network adapter (both tun
> and ovpn-dco) and get network routes set up properly.

My guess in this thread here is that the systemd unit files used by
the original poster are not granting these two capabilities.  Otherwise,
I fail to come up with a reason why OpenVPN would be able to change
user, but not retain CAP_NET_ADMIN.

(But then, as you know I'm not a big fan of Systemd's overarching
"WE MUST DO THINGS NO MATTER THE COST" tendencies, with private /home,
private /tmp, getting in the way of getting work done in big ways)

> I strongly encourage everyone to start OpenVPN, especially server
> configurations, via the systemd unit files provided by the OpenVPN project.
> This will attempt to reduce the privileges the OpenVPN process needs to do
> its job.

OpenVPN 2 does a pretty good job in doing so :-) - so, the best thing Systemd
can do here is "do not mess with OpenVPN".

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] --user specified but lacking CAP_SETPCAP

[Marc SCHAEFER]

> used to allow the OpenVPN process to keep setup certain capabilities as it
> transitions to the user provided via the --user option.  The CAP_NET_ADMIN
> is, not surprisingly, used to setup the virtual network adapter (both tun
> and ovpn-dco) and get network routes set up properly.

And, if you run OpenVPN within a Docker container, you will need to manually add
that capability at the Docker container creation time:

   --cap-add=NET_ADMIN


___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] --user specified but lacking CAP_SETPCAP

[David Sommerseth]

On 24/10/2023 07:46, Peter Davis via Openvpn-users wrote:

Hi,
I see the same message. Linux capabilities? Should I install any package or...?



Linux capabilities is a security feature provided by the kernel.  For 
OpenVPN (or any other tunneling software, in fact), certain capabilities 
(such as CAP_NET_ADMIN) are required to modify network settings, 
changing network routes or creating and removing virtual network 
interfaces.  Other capabilities gives other privileges on the system.


The root user, by default, is granted all capabilities.  Ordinary users 
on the system does not have any capabilities enabled by default.


When starting OpenVPN via the openvpn-client@.service or
openvpn-server@.service systemd unit files, some capabilities are 
granted to the the OpenVPN process may transition to, like the "openvpn" 
user.  CAP_SETPCAP and CAP_NET_ADMIN are two of those.  The first one is 
actually used to allow the OpenVPN process to keep setup certain 
capabilities as it transitions to the user provided via the --user 
option.  The CAP_NET_ADMIN is, not surprisingly, used to setup the 
virtual network adapter (both tun and ovpn-dco) and get network routes 
set up properly.


I strongly encourage everyone to start OpenVPN, especially server 
configurations, via the systemd unit files provided by the OpenVPN 
project.  This will attempt to reduce the privileges the OpenVPN process 
needs to do its job.



If you want an OpenVPN client setup running with the least privileges 
possible, you could have a look at the OpenVPN 3 Linux project [0]. 
This project attempts to go even further by splitting up the 
responsibility of the client connection (keeping the link to the server, 
encrypting/decrypting traffic) and the network configuration (creating 
the virtual interface, configuring VPN IP addresses, network routes and 
DNS) into separate components.  The client connection component runs 
completely unprivileged while the network configuration component runs 
as a separate process without any root privileges, just CAP_NET_ADMIN 
and a few other selected ones (depending on the host configuration).


This ensures the privileged network configuration process can only do a 
set of limited operations on the host, while the unprivileged client 
process can only pass traffic to and from the server, do the needed 
crypto operations on that traffic and send that traffic to/from the 
local virtual interface.



[0] 


--
kind regards,

David Sommerseth
OpenVPN Inc




___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

[Openvpn-users] OpenVPN 3 Linux v21 released

[David Sommerseth]

OpenVPN 3 Linux v21 (stable)

This announcement comes a bit delayed as we have spent time ensuring
brand new software package repositories for both .deb and .rpm
packages are working properly.

We have now introduced a set of repositories suitable for production
environments.  These new repositories will only ship stable releases
which has been through a full set of quality assurance testing.
Packages in this repository will primarily focus on packages for
enterprise and long-term support Linux distributions, such as Debian
stable, Red Hat Enterprise Linux and Ubuntu LTS releases.

Fedora Copr repositories will still be used, but will also ship
development and beta releases.  We are also working on establishing
a similar repository for .deb packages too.  The Fedora Copr and the
coming repository for .deb packages will target faster moving Linux
distributions, such as the Fedora and the non-LTS Ubuntu releases.

   *NOTE*   The repository used for .deb packages up to
   *NOTE*   OpenVPN 3 Linux v20 will no longer receive
   *NOTE*   any updates.  You *MUST* setup the new
   *NOTE*   repository for .deb packages to receive the
   *NOTE*   OpenVPN 3 Linux v21 release

The community wiki has been updated with information how to enable
the new repositories, for both .deb and .rpm based distributions:



Over to the OpenVPN 3 Linux v21 details ...

Thais primarily a maintenance release with several minor bug fixes
and some general improvements.

*HOWEVER*, due to issues related to newer glib2 versions on
Arch Linux, Fedora and non-LTS Ubuntu releases, the v21 release
is targeting *only Enterprise/LTS distributions*.  The glib2
integration is going through a large overhaul to work better with
newer versions.  There will come a separate development release
for these distributions once that work has completed.  Details
related to this work can be tracked in this ticket:




* Improvement: Upgrade OpenVPN 3 Core Library to v3.8.2

   This is an upgrade from Core Library 3.7, which provides more
   enhancements and adds support for the newer ovpn-dco-v2 kernel
   module.  This is the same kernel module version OpenVPN 2.6
   supports.


* Bugfix: OpenVPN 3 Linux AWS VPC lacks support for IMDSv2

   mattjbyrd reported the AWS VPC integration was not working with EC2
   instances where IMDSv2 was enforced.  This issue is resolved with
   the OpenVPN 3 Core Library upgrade.

   Details: 


* Bugfix: Python StatusCallback did not work without LogCallback enabled

   Jeremy Fleischman reported an issue related the openvpn3 Python
   module did not work when just setting up a
   SessionManager.StatusCallback() method.  He provided a fix which is
   now included in v21.  Thanks a lot, Jeremy!

   Details:



* Bugfix: openvpn3 config-manage override may not always work

   The openvpn3 config-manage override options would in some cases not work
   due to a programming error related to an internal set_override() method
   and the SetOverride() D-Bus method.  The result was that typically
   string values ended up empty.  Now all the overrides can be configured
   again.


* Bugfix: OpenVPN 3 Python based configuration parser issues

   Several options and --profile-overrides did not work or was completely
   missing, like the dns-scope and allow-compression overrides.  This
   has been improved and the list of overrides should now be up-to-date
   with openvpn3 config-manage.

   The Python based option parser also did not fully support overrides
   with a boolean true/false setting properly.  This has also been
   fixed.


* Improvement: Detect needed host specific settings during package install

   The OpenVPN 3 Linux v20 introduced the openvpn3-admin init-config
   command.  This has been further improved and will now be run
   automatically during the package installation.  This command will
   probe the system for important features on the system, like what
   kind of system logging is in use, what kind of DNS resolver
   approach being available (systemd-resolved, /etc/resolv.conf) as
   well as doing other sanity checks, like if the needed openvpn
   user/group is present, important directories being configured
   correctly and that SELinux based systems have the proper file
   contexts set up.

   The default behaviour is that existing configuration changes done
   will NOT be overwritten.  But if no settings has been set, it will
   generate configurations files better matching the running system.


* Improvements: OpenVPN 3 Log Service

   The OpenVPN 3 Log service (openvpn3-service-logger) made it
   hard to track where Attached: and Detached: log events came
   from.  This does now add a PID reference, which can be traced
   more easily in the logs.