On 26/10/2023 18:22, Gert Doering wrote:
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.
Depends on how the distribution packaging has done anything additional
to the the OpenVPN upstream unit files. I know it works smooth in the
RHEL packaging.
Some distros still ship the "openvpn.service" havoc, which may be used -
this may also mess up things badly. Or users have their own variant
of a .service file which also doesn't account properly enough for
capabilities.
My point is: Ensure the proper OpenVPN package provided unit file is
used and use the openvpn-{client,server}@.service unit files. That's
the first step to make OpenVPN run properly. Unit files not provided by
the OpenVPN project may indeed be as bad as a home grown sys-v init
script which doesn't do all the needed things OpenVPN or the system
itself expects.
(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)
That's an entirely different discussion. But if you actually started
using a modern Linux distribution which has fully embraced systemd
(RHEL, Fedora, Debian, Ubuntu, and their clones), there are seldom any
issues these days holding me back. Those times I'm "held back" is when
I do something which I then realise was stupid to do as a starter. One
of these "stupid things" is to cling to the "sys-v init script era way
of doing things". That approach will definitely cause pain.
The approaches used back in the days was suitable back then. Today's
environments have different requirements, as they are running in faster
changing, dynamic environments, with a completely different set of
security challenges.
This "systemd is bad by design" argument is more of an attitude problem
than an implementation issue. Okay, it's not perfect, but it's usually
far better than the alternatives for most use cases - for today's
challenges. And yes, there are some use cases, where systemd doesn't
fully work as well as it could and should. But for the vast majority of
Linux users, it's more than enough today.
The more I use it and the more I integrate code to work with it, the
easier my work ends up being - and my code can run with lesser
privileges out-of-the-box. I have also written code which enables
unprivileged users to turn on/off OpenVPN sessions at boot time in a
controlled manner. And that's by just using features which is available
today in systemd's toolbox; all it took was to add a policy
configuration and use the proper systemd APIs and that's it.
Systemd does have a broad reach on the system - because it is a *system
management service*, to ensure all the pieces and cogwheels in the
system is running correctly. For example, allowing selected users (or
groups of users) to manipulate the system in a controlled manner without
giving them full root access, and giving them access to only change what
they're supposed to change - that's a huge step forward in system
security and ensuring runtime stability. And it's available
out-of-the-box on a modern Linux distribution today.
But systemd is still not perfect, I agree. But the missing features and
lack of capabilities to give even more finer grained access are
improving the whole time. And my experience is, despite not being
perfect, that it still is far better than the alternatives.
In the end ... securing, hardening and ensuring a system runs stable,
that does have some user experience costs - just like it's been a huge
change in the Windows world too, going from the Win95 "you're all admins
by default" to all the limitations you'll face out-of-the-box in Win11.
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".
OpenVPN 2 out-of-the-box without systemd (or any other execution
strategy restricting capabilities in advance) will have lots of
possibilities on the host. Systemd in OpenVPN 2.x context just ensures
the process is started with as few privileges as possible to start
running. Which can reduce the possibilities of a
misbehaving/misconfigured OpenVPN to actually do unexpected harm to the
system.
Systemd monitors the OpenVPN process, collects logs in way making it
easily available, and in the server context, ensures it is restarted if
it stops unexpectedly.
Systemd doesn't "mess with OpenVPN". It just ensures OpenVPN doesn't
mess with your system and helps it running in a controlled and managed
way. As that's what a system management service is expected to do.
So it depends on the angle you look at it from: What is more important?
Your overall system behaviour or just OpenVPN?
--
kind regards,
David Sommerseth
OpenVPN Inc
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
