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/resolver-backend-interface.hpp> > > > 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/resolver-settings.hpp> 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@xxxxxxxxxx PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
