On 2/25/21 4:50 PM, David Sommerseth wrote:
Hi!
On 25/02/2021 14:39, Petr Menšík wrote:
[..snip...]
>
> This case is exactly what I am trying to prevent. There is multiple
> implementations of dns cache, most of them can support split-DNS by some
> configuration. If openvpn supports systemd-resolved natively, does that
> mean it would not be able to support split-DNS on dnsmasq or unbound?
> What is motivation to support specific implementation instead of generic
> interface? I don't want to ask openvpn to support also dnsmasq or
> unbound natively, because I think there should be middle layer support.
> I am trying to use resolvconf as such layer.
systemd-resolved is already enabled in Ubuntu 18.04 (but not fully) and
now in Fedora 33 (which goes a long way of integration into the system).
It also provides a D-Bus interface which is reasonable to integrate with.
This solved use cases we have for customers connecting Ubuntu machines
to OpenVPN Cloud, where DNS is a big part of the Cloud solution.
> I am dnsmasq, unbound and bind (co)maintainer. I want them to stay first
> class citizens in Fedora, even when they are not installed by default.
> Of course, also knot-resolver and pdns-recursor should be supported, if
> they are (willing and) able to.
dnsmasq and unbound are great packages as well, but they are not really
designed for system integration in the same level as systemd-resolved
when considering today's ever changing network topology. Just take an
average laptop user today - how many various networks might that user
connect during a day, especially when travelling?
I have been using dnssec-trigger, which acts as DNSSEC enabled and
unbound split DNS provider for 4 years, also during travels on train. I
admit it hit some issues on weird networks, but nothing serious. dnsmasq
also has good integration with Network Manager, just use dns=dnsmasq. I
disagree they are not ready for laptop users. They both work fine. And
both do not block DNSSEC by default like systemd-resolved does.
Since we have the impression systemd-resolved is becoming more and more
used by default, we figured that would be a reasonable service to
integrate with. It also seems to handle the various use cases of
roadwarriors pretty well as well as virtualised servers. Plus it
provides a reasonable D-Bus API to work with (more on that below).
I am not sure it
is becoming default for its quality or its push from
systemd developers. Sure, it is whole driven by dbus. Dnsmasq has split
DNS configuration available from dbus, it just is not enabled by
default. None of more serious DNS caches has dbus interface I think.
OpenVPN 3 Linux aims to run with as least privileges as possible. And
tt tries to integrate with the basic existing network components on the
system. But running with least privileges is a challenge with lots of
the network stack, as it requires some elevated privileges. So
OpenVPN 3 Linux is split up into several components doing a dedicated task.
By the way, how would OpenVPN 3 work on windows, where I expect dbus
support is missing? Does it have similar equivalent also to
systemd-resolved local cache? Can it archieve split DNS?
== Some OpenVPN 3 Linux architecture details ==
The most privileged service running is the openvpn3-service-netcfg
(net.openvpn.v3.netcfg). This is responsible for creating and configure
TUN interfaces (with or without kernel acceleration), setting up routes
and DNS. But it runs as the openvpn:openvpn user with CAP_NETADMIN. If
using the resolv.conf approach (currently the default, which edits
/etc/resolv.conf directly - which IS nasty), it also adds CAP_DAC_OVERRIDE.
It is
about 2 years when we were removing CAP_DAC_OVERRIDE from our
services, because selinux-policy does not grant it anymore. I think it
is a good thing. Running as openvpn user, but requiring then
CAP_DAC_OVERRIDE is insecure! It gives it more rights than just root
users without this permission would have. I would suggest reconsider
such design and run netcfg as root, just with dropped capabilities
except CAP_NET_ADMIN, if it needs to modify resolv.conf. resolvconf call
should not pose significant threat.
But we generally try to avoid exec() any external code and depend on
available APIs on the host, whether it is Kernel Netlink, libc related
interfaces or D-Bus. In fact, the script-hooks found in OpenVPN 2.x is
non-existing in OpenVPN 3 Linux.
In such situation, calling resolvconf as a helper seems secure enough. I
don't see any value in avoiding exec(), when CAP_DAC_OVERRIDE were not
first to purge. Please reach to selinux-policy maintainers to discuss
the best solution. I think DAC_OVERRIDE should be avoided if possible,
let them confirm it.
You can however achieve similar features (but with some more work
currently) by subscribing to various D-Bus signals OpenVPN 3 services
sends. The openvpn3-addon-aws is such a service, which propagates
pushed VPN routes to a AWS VPC setup and removes them again when the VPN
connection is taken down.
In regards to network configuration and DNS resolvers. The
openvpn3-service-netcfg module is written in a way so it should be
possible to extend it with more "resolver setting backends".
A new backend needs to implement this interface:
<
https://github.com/OpenVPN/openvpn3-linux/blob/master/src/netcfg/dns/reso...
Each running VPN session provides the DNS resolver settings via
ResolverSettings objects, which are gathered via the Apply() method. And
once all settings are provided, the Commit() method is called which
makes sure the settings are happening on the host.
The ResolverSettings class is defined here:
<
https://github.com/OpenVPN/openvpn3-linux/blob/master/src/netcfg/dns/reso...
Even systemd-resolved is improving, it still has some limitations.
DNSSEC is still disabled by default. I don't think it should depend only
on dbus enabled services only. But perhaps I have to acknowledge not
only server services with their own remote control tools are good for
everyone.
Thanks a lot for resources to study. I will try to read it a bit and adjust.
Regards,
Petr
--
Petr Menšík
Software Engineer
Red Hat,
http://www.redhat.com/
email: pemensik(a)redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB