dnssec-trigger + GNOME + NetworkManager integration

[Tomas Hozza]

On 26.06.2015 17:13, Matthias Clasen wrote:
> On Tue, 2015-06-23 at 18:43 +0200, Tomas Hozza wrote:
> 
> Hey, I was out for a week, so this may be a bit of a late reply.
> 
> As Michael and Bastien already stated, all the GNOME networking UI
> relies on information gotten from NetworkManager, and we'd like to keep
> it that way. In particular, NetworkManager has an existing API to
> inform us about captive portals - if at all possible, you should keep
> that working.

Yes, it should work. We didn't change anything related to that. We just
had our own implementation.

> [...]
> 
>> 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
> 
> My perspective on this is that we already have a UI: GNOME shell
> displays network status, including captive portal. If NetworkManager
> needs to add a few more connection states related to DNSSEC, we can
> adapt to that.

The thing is that some information are unrelated to NM. There is no
reason to push all information back to NetworkManager, since its role is
explicitly defined - manage network connections and leave the DNS
resolution and configuration up to different tool.

> GNOME shell also launches a browser when needed for captive portal
> login. If we need to tweak the way the browser is launched to make it
> work on a dnssec-enabled system, that should be possible.

I was not able to determine if you rely on the system's stub resolver.
If that is the case, NM should notify GNOME only after dnssec-trigger
switches to "hotspot signon mode".

>> 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
> 
> This seems dubious, at best. What does it mean if my system is
> 'insecure' ? Will my credit card number be stolen ? Will my system be
> taken over by intruders if I don't disconnect immediately ? Most users
> will have no idea, and have to treat such a switch either as "scary,
> don't touch" or as the "fix the internet" button.

It means that the site of your bank you are on may not be provided the
actual host you should be connected to, but instead by some attacker's.
The insecure mode means that you are vulnerable in the same way as the
plain DNS is. So you are insecure even now if you don't use DNSSEC
without realizing it.

> I could see adding information regarding the dnssec status of
> connections to the network panel. For that to happen, the information
> needs to be represented in the nm connection configuration, e.g. in
> NmSettingIP4Config, which already has settings like "ignore-auto-dns".

We can determine if the connection provided DNS resolvers are usable for
DNSSEC validation, but that's it. There is no such thing as secure
connection from DNS/DNSSEC point of view. The DNS resolvers for global
name resolution are always taken from the default connection (if these
are able to provide DNSSEC data) or full recursion is used or Fedora
fallback infrastructure is used. Then for VPNs explicit forward zones
are configured, with VPN provided DNS resolvers.

So the bottom line is, that it does not make sense to distinguish
security status of a connection from DNS/DNSSEC point of view, but
rather the security status of the whole system and DNS resolution as a
service provided by the system via stub resolver.

>> 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
> 
> I would encourage you to ship it separately as such, then. I don't even
> think it needs to be a graphical tool, a commandline utility would be
> just fine for this purpose.

There is already a commandline tool that does all the things the GTK
panel does.

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

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