D-Bus service activation and access control

[David Sommerseth]

On 31/07/17 18:46, Thiago Macieira wrote:
> On Monday, 31 July 2017 03:35:53 PDT you wrote:
>>> Out of curiosity: is any of this needed considering NetworkManger already
>>> does all of it?
>>
>> That is going to be resolved at a later stage, and we don't want to tie
>> ourselves to NetworkManager alone.  I'm having systemd-networkd support
>> open as well, plus we're not quite sure what will happen on *BSD (which
>> we have seen have some D-Bus packages available).  So while we do
>> currently target Linux, we try to not make it too difficult to at least
>> enable this new code base on other *nix oriented OSes.
> 
> What problem are you trying to solve at all?
> 
> OpenVPN already works and almost all Unix systems already have a way of 
> managing it. Heck, I even have it on my Android phone, even though I had to 
> figure out which of the applications actually worked.
>
> NM can manage its configuration and is rather complete. I have some weird 
> settings in my VPN and I found that all settings can be properly configured in 
> the UI. NM will start and stop the openvpn process just fine.
> 
> So, what problem are you trying to solve?

I am working on a brand new OpenVPN client.  The commonly used
OpenVPN 2.x code base is written as a pretty normal C application.  The
OpenVPN 3 core code base is a complete re-write in C++, which is written
as a library - this code is the basis for the "OpenVPN Connect" on
Android and iOS which is already available.  So when writing a brand new
client for Linux, we wanted to take advantage of the new mechanisms
modern Linux distributions provides.

OpenVPN 3 will also gain more advanced features which will be much
harder to implement in OpenVPN 2 as well.  Since OpenVPN 3 is also
written as a C++ library, it makes it easier to extend it in many areas
without adding much additional core code.

Now, the OpenVPN 2.x code base does work reasonably well for most use
cases today.  But there are plenty of issues which needs special care -
especially when SELinux and similar mechanisms is enabled, like
PKCS#11/Smart Cards, strict file access (like files from $HOME/.cert),
etc, etc.  The OpenVPN 2.x code base was released about 15 years ago,
and it haven't really paid too close attention to how the world have
moved forward in many areas.  The most challenging side on the server
side is that OpenVPN 2 is single threaded, with its own event handler
implementation (as the event handlers 15 years ago did not perform well
enough).

So the current design builds around splitting up the OpenVPN client
processes into smaller pieces which can run independently with as little
privileges as strictly needed - and have the IPC happening over D-Bus
(at least for the Linux and with time *BSD).  And at the same time
enable unprivileged users on multi-user systems to establish VPN tunnels
independently (as long as the policy allows it).  Since D-Bus and polkit
have lots of these mechanisms in place already building on such a
framework makes a lot of sense to us.

Currently we have a focus on the OpenVPN 3 client side, and once that
settles we'll take a stab at the server side as well.  But there are
generally more clients than servers in use, so starting on the client
side first seemed more reasonable - that gives us lots of testing on the
same code paths which will be used on the server side as well.

> And while you're solving it, are you sure you're not breaking everyone else? 
> You need to keep the openvpn process available and parsing both config files and 
> command-line arguments as-is anyway.

It is currently a feature gap between OpenVPN 2 and OpenVPN 3, which we
are carefully considering.  OpenVPN 2 have over 230(!) options. (A bit
too) Many of them are fairly obscure, some also have an impact on the
tunnel security and others are just simply not needed on more modern
OSes.  But we will carry those options which are really relevant and
important.  Just as NM-openvpn also don't support a lot of the various
options we have today.

But the option parser in OpenVPN 3 is written to be able to parse
existing configuration files, so as long your OpenVPN 2 configuration
don't use unsupported features in OpenVPN 3 it should work out-of-the
box.  I've already ran several tests on this, with great success.  The
most interesting detail is that establishing a tunnel happens within
3-400ms with OpenVPN 3, with OpenVPN 2 it can easily take 2-3 seconds.

All that said; OpenVPN 2 will continue to live along side OpenVPN 3 for
a noticeable time - at least until we have both client and server
support in OpenVPN 3.  We will _not_ do a hard-drop of OpenVPN 2 any
time soon.  But once we have a critical mass using OpenVPN 3 client and
server components, OpenVPN 2 will get a sunset plan.


-- 
kind regards,

David Sommerseth