Re: --user specified but lacking CAP_SETPCAP

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 [email protected] or
>> [email protected] 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