[Dnssec-trigger] New dnssec-trigger NM dispatcher script

[Paul Wouters]

On Wed, 22 Jan 2014, Tomas Hozza wrote:

> What about the "secured corporate" wifi network situation I described before?
> I personally see a use case also in wifi networks, but I agree that it is hard
> to come up with a really good solution. I'm willing to improve it in some way
> if you have any constructive ideas (in the constraints of current possibilities),
> but stopping the addition of forward zones for wifi connections completely is
> also not a good idea by my opinion.

> I agree with this. Unfortunately at the moment it is not possible in the
> NM UI and will require even further NM integration (which is planned,
> but will not happen over night).
>
> The plan is that the configuration file could be at least partially
> used by NM in the future. This way we will be able to at least provide some
> backward compatibility with the current solution that uses dnssec-trigger.
> Therefore we think it is not a good approach to leave the configuration
> solely in dnssec-trigger dispatcher script.
>
> The motivation here is to improve the current situation due to some
> issues I described before, in the constraints of current possibilities,
> rather than implement the best possible solution later on (which will
> anyway happen).

Let me try and summarize what I think is the problem.

You have interpreted the "domain" entry in /etc/resolv.conf as being the
LAN's domain and the nameservers from /etc/resolv.conf as being the IP
addresses of the nameservers that can resolve the "domain".

However, that is not what those entries mean. The "domain" entry means
that if you are going to send an unqualified (non-FQDN) query, and you
don't get a result, you may try again my apending the "domain" entry.
The IP's of nameservers are nothing more than the IP of nameservers.
They have no relationship to the "domain" entry whatsoever.
On modern systems, these values are populated by DHCP.

Thse two interpretations are different, which is the source of the
security issues.

Sometimes, people have created relationships that _does_ equate these
two different interpretations. So if you have a "domain" of
"internal.redhat.com" and nameservers 1.2.3.4,5.6.7.8 than it is implied
that you can lookup this custom non-world view domain using these
nameservers. What you are suggesting is that _all_ networks are like
this. While I am saying we should not _always_ assume this.

So the design work here is to come up with a scenario that:
- Does not degrade security
- Does not burden the user with making this choice

We mentioned a few possibilities:
- Assume ethernet connectivity implies the user's consent in trusting
   the network, allowing the above assumption to be made
- Assume VPN configurations always override LAN settings
- What to do with Wifi (we disagree here on what to do)

On this last point, I think we have a few policy options we can choose
  from, compromising based on reducing user interactivity and NM changes:

- Wifi is untrusted, never redirect the received "domain" to the
   received nameserver IP's, unless the user manually tells us to do so
   [ policy easy to implement, but requires non-trivial NM changes]
- If ESSID was known and automatically joined, trust the wifi and make
   the domain/ns binding [I say this is insecure, because my laptop
   auto-joins networks it has never been on if the name happens to match,
   like "linksys" or "PublicWifi", or by active attacks like people
   setting "redhat.com" on purpose to trick me]
- If non-open Wifi, assume trust like physical wire. Eg WPA, EAP.
   [ I am fine with this ]


I hope I clarified that I think we cannot have this resolv.conf mapping
of domain name and namesevers IP unconditionally, which is what the
current python hook seems to do.

Paul