dnssec-trigger + GNOME + NetworkManager integration

Tue Jun 23 16:43:08 UTC 2015

Hi all.

I would like to start a new fresh discussion where we can hopefully
converge towards successful integration of default DNS resolver with
NetworkManager on Fedora Workstation (GNOME).

I think there are (at least) two major issues that need to be resolved:
- system-wide Captive Portal detection
- proper UI integration

How is dnssec-trigger integrated with NM
----------------------------------------
I'll start briefly with what dnssec-trigger does and how it is
integrated with NM, so we are on the same boat.

We use Unbound as local DNS resolver that does also DNSSEC validation.
It needs to be configured with proper DNS forwarders in order to do the
validation successfully.

Dnssec-trigger is a daemon and script that reconfigures Unbound
dynamically on every network change (using NetworkManager dispatcher).
In our intended setup, dnssec-trigger handles the content of
/etc/resolv.conf. It gathers all the current configuration from NM using
libnm-glib. This means that we are able to handle any connection that NM
is aware of, including VPNs and split DNS configuration. Our goal is to
do DNSSEC validation whenever possible, therefore we have also public
fallback Fedora infrastructure or DNS resolvers running on port 443.

Since dnssec-trigger handles resolv.conf and reconfigures Unbound, NM's
purpose is to do all the network configuration EXCEPT DNS related
configuration.

Captive Portal
--------------
Dnssec-trigger also handles Captive Portal detection, since this
situation is most of the times DNS spoofing attack and DNSSEC is exactly
the mechanism that should protect users from such attack.

Now we know that we have at least 3 components on the system, that are
trying to do the same thing - Captive Portal detection:
- dnssec-trigger
- NetworkManager
- GNOME Shell

We don't have a problem with turning the detection off, however we need
to agree on system-wide solution that works properly.

We already know that the Captive Portal detection in NM relies on the
system stub resolver, however after our previous discussion I was under
the impression that there are some plans to rework it. Is this correct Dan?

I hope that GNOME Shell somehow only displays the state provided by NM.
Bastien, please correct me if I'm wrong and please elaborate on the
details of what the functionality does (e.g. if you launch a new browser
or so).

In dnssec-trigger the detection is done by resolving a predefined
hostname using DHCP-provided resolvers, downloading a remote file and
then comparing the actual content with what was expected. This may not
be perfect, but is mostly works. The important point is that DHCP
provided resolvers are queried directly, not via system stub resolver.

On the other hand, if NM dispatcher would be able to notify other
services in case of detected Captive Portal, dnssec-trigger would be
able to add the correct DHCP-provided resolver into the resolv.conf for
the purpose of Logging into the Captive Portal. This is mainly due to
the browser window using system's stub resolver.

UI integration
--------------
Now the dnssec-trigger comes with not really well integrated UI
(dnssec-trigger panel) [2]. The panel is written in GTK2 and resides in
the already deprecated status panel (on the bottom of the screen). It is
used mainly for the following interaction with the user:

- Inform the user about Captive Portal, in case there is one (to allow
user to switch into so called "hotspot signon mode") by pop-up window
- enable user to switch to "hotspot signon mode" (basically insecure
mode) manually
- enable the user to reprobe DHCP-provided DNS servers if these are
DNSSEC enabled - meaning to test if these are able to provide all the
data needed for DNSSEC validation.
- inform user in case the local network-provided DNS servers don't
support DNSSEC and the local network blocks outgoing DNS communication
on standard DNS ports and also when tunelled - in other words, user much
choose between insecure mode or disconnecting from the network.

This boils down to what we need from some new version of the UI that we
need to be well integrated with GNOME:

1. Be able to inform user about some situations (Captive portal
detected, network blocks all DNS communication, ...) and enable the user
to take an action. (This could be possibly done by the notifications
system in latest GNOME)

-> this may be solved also in GNOME already, and may be OK if done
technically correctly. Please note my note earlier on NM notifying other
services when Captive Portal is detected

2. Possibly have some indicator showing if the system is in "Secure" or
"Insecure" state.

3. Enable the user to switch between those two states manually

4. Additionally enable the user to trigger the reprobe of
connection-provided DNS resolvers and display result of the probe (last
one).

-> this should not be needed for regular use. It is more of a debugging tool

[1] https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
[2] http://www.nlnetlabs.nl/projects/dnssec-trigger/#screenshots

I'm all for simple and clean integration. Let's identify specific
solutions and pieces we can start working on.

Thanks.

Regards,
-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
Red Hat Inc.                 http://cz.redhat.com