F23 System Wide Change: Default Local DNS Resolver

[Petr Spacek]

On 12.6.2015 18:53, Dan Williams wrote:
> On Fri, 2015-06-12 at 17:10 +0200, Petr Spacek wrote:
>>> On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
>>>> On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
>>>>> decision needs to then be made by the system. I believe that's been
>>>>> mostly due to lack of time for the various parties to sit down and
>>>>> plan and then program this further.
>>>>
>>>> We should try to make that happen.
>>
>> Okay, let's start once again from scratch.
>>
>> All of this was already discussed and we even had a huge meeting around
>> DevConf and FLOCK 2014 about this, so following text will be just a short
>> refresher:
> 
> Yeah, we did.  From my recollection, most of that focused on the unbound
> parts and how NM could add the dns=unbound stuff (which Pavel
> contributed) but less on the NM connectivity checking, becuase Fedora
> hadn't turned that on by default yet.  I'm all fine with dns=unbound,
> that's not the issue.  The issue is more around what happens with NM's
> connectivity checking, since that's used by quite a few clients,
> including GNOME Shell.
> 
>> The ultimate goal
>> =================
>> Make various man-in-the-middle attacks *automatically* detectable - without
>> any user interaction. Especially we want to get rid of dialogs like "Site
>> www.gmail.com is using certificate issued for xxx.porn and certificate's
>> validity ended 10 years ago. Do you want to continue? [YES] [YES] [YES]".
>>
>>
>> Tools
>> =====
>> To achieve this goal we need to do DNSSEC validation on every client machine
>> (ignoring Docker for a moment, see below) and allow applications to use DNS as
>> trusted source of sensitive data (certificate fingerprints, SSH fingerprints,
>> etc.).
>>
>> DNSSEC allows all parties to publish their fingerprints in DNS and gives us a
>> secure way to get the data and to detect that someone prevents us from getting
>> the data.
>>
>>
>> Longer description
>> ==================
>> http://developerblog.redhat.com/2015/04/14/writing-an-application-that-supports-dnssec-in-rhel-and-fedora/
>>
>>
>> First step: DNSSEC validation
>> =============================
>> Contemporary networks are full of broken DNS proxies so we need to jump
>> through various hoops to get non-faked DNSSEC data for DNSSEC validation.
>>
>> The goal of this step is to get *cryptographical* proof that the data we
>> received are the same as DNS zone owner published.
>>
>> This includes two sub-problems:
>> a) Hot-spots:
>> Captive portal detection needs to allow user to disable all the security so he
>> can log-in but this needs to be done in a secure and reliable way so an
>> attacker cannot misuse this.
>>
>> b) Broken networks:
>> Some networks are so broken that even without captive portal they are not able
>> to deliver DNSSEC data to the clients.
>>
>> In that case will try tunnel to other DNS servers on the Internet (Fedora
>> Infra or public DNS root) and use them. Naturally, local/internal domains need
>> to be available.
> 
> While I don't actually care, this might well be a sticking point for
> many people since their DNS information is going to an untrusted (to
> them) DNS server.  Yeah, I tend to trust Fedora, but not everyone will.
> Can the tunnel be turned off, or the broken servers whitelisted, or is
> the answer here to just "dnf remove dnssec-trigger"?
> 
>> All these sub-problems (including VPN handling an so on) are solved by
>> dnssec-trigger with tweaks by Tomas Hozza and Pavel Simerda.
>>
>>
>> HERE we need to coordinate with other parties who might want to write into the
>> /etc/resolv.conf file. These include (but might not be limited to):
>>     NetworkManager
>>     initscripts
>>     dhclient
>>     libreswan ?
>>     resolved
>>     connman
> 
> pppd, vpnc, openvpn, etc. should get added to the list since they all
> have scripts that can potentially write to /etc/resolv.conf.
> 
>> Option is either to implement all the checks and workarounds in all the
>> projects over and over or to implement all the logic in one place -
>> dnssec-trigger might be such place.
>>
>> Anyone who is going to write to resolv.conf needs to check for captive
>> portals, find a DNSSEC-enabled DNS server, and deal with VPN-provided DNS
>> servers and domains.
>>
>> *Questions:*
>> Guys, what are your plans for handling the situations mentioned above?
>>
>> Can we integrate on one place (e.g. by calling into dnssec-trigger) instead
>> overwriting /etc/resolv.conf independently?
> 
> This is the real issue.  It sounds like What you're proposing is to make
> dnssec-trigger into the "DNS broker".  The previous solutions
> (resolvconf, NetworkManager, etc) have all failed for various reasons.
> Touching/changing something so fundamental to the system, as you've
> probably discovered, can be hard...
> 
> systemd-resolved might have a chance here, since it's small and pretty
> simple, but they don't have an external API and don't seem interested in
> creating one any time soon which severely limits it's usefulness.
> 
> If this is indeed what you're proposing, then lets have a discussion
> about dnssec-trigger+unbound in that context, I do have some thoughts to
> contribute here.

You understand it correctly, speak up! :-)

Generally the problem is that resolv.conf is quite limited and cannot express
lot of things, like trust levels and per-domain forwarding (using different
servers for queries related to different domains).

One possibility how to solve this is to port applications to use different
library/API for name resolution but we have learn that this is not feasible
(recall the "everything to NSS" effort).

Another alternative is to let it be as it is, which is easiest for now but it
does not allow us to handle VPNs in the proper way and has worse
security/privacy implications.

The last option I can see is to modify applications which which *modify*
/etc/resolv.conf to use some API to pass the information to a central place
(be it dnssec-trigger or something else) and solve this by machinery added on
top of Unbound or other DNSSEC-validating resolver. It is quite a bit of work
but still, this should be *much* easier than modifying all *client*
applications to use different API and is almost 100 % backwards compatible.

I'm very open to other ideas how we can solve this problem in an elegant, easy
way.

Petr Spacek  @  Red Hat

>> Second problem: API for applications
>> ====================================
>> (this second step is not part of the F23 feature but it is worth discussing)
>> Applications and crypto libraries need "an" interface to get DNS data which
>> are either 100 % correct or declared as not trusted. False positive (trusted)
>> answers are simply unacceptable because that would allow serious attacks.
>>
>> Imagine that OpenSSH client is verifying server's fingerprint against the
>> value obtained from DNS *instead of asking the user*. If the client accepted a
>> fake response with faked server's fingerprint then everything is doomed.
>>
>>
>> The proposal https://sourceware.org/ml/libc-alpha/2014-11/msg00426.html on
>> glibc mailing list is to extend getaddr API with flag which says 'secure
>> answers only'. This will return an answer only if DNSSEC validation for given
>> answer was successful and the answer was properly signed.
>>
>> The assumption here is that something like dnssec-trigger properly configures
>> local resolver (using the information from DHCP + applying all the necessary
>> workarounds) to do DNSSEC validation locally so we are 100 % sure that the
>> fake answer can be detected.
>>
>> The open question is how to pass the information about security status to all
>> the parties. The mechanism needs to be simple so other resolver libraries like
>> e.g. python-dns can follow the same rules and use the same logic as Glibc.
>>
>> Possible states:
>> a) We are in hot-spot sign-on mode or validating resolver is unavailable for
>> some reason (early boot, resource constraints, Docker container [finally!],
>> and so on):
>>
>> In this case *nothing* can be trusted. Resolver might return faked answers and
>> we have no means to check if declared trustworthiness is correct or not.
>> Again, we need to be 100 % sure from the cryptographical point of view.
>> => Application MUST NOT receive any answer marked as "secure"/"trusted" if we
>> are in this mode.
>>
>>
>> b) Validating resolver is up, running, properly configured, and the path to
>> the resolver is trusted - it might be running on localhost or we are in Docker
>> container and we trust the host and so on.
>>
>> In this case we trust to the result of validation indicated by AD bit.
>> Application will receive the answer marked as trusted if the resolver tells us
>> to do so by AD bit in the DNS reply.
>>
>> Please read the post on Glibc mailing list for more details.
>>
>> Any suggestions how to do that are more than welcome!