Building consensus over DNSSEC enhancements to glibc.

[Simo Sorce]

On 17/11/15 02:19, Carlos O'Donell wrote:
> On 11/17/2015 12:55 AM, Paul Wouters wrote:
>>> Optionally NetworkManager via resolvconf (coordinating
>>> /etc/resolv.conf changes) could set the option if only one insecure
>>> public network was connected to the system.
>>
>> So indeed, this is an insecure solution. One write to
>> /etc/resolv.conf and all trusted applications are compromised.
>> Applications like gpg or ssh or openpgpkey-milter or even browsers
>> checking TLSA records should not bet their security on this.
>
> A system configuration is as secure as the servers in the trusted
> /etc/resolv.conf file. If you want secure DNSSEC then set /etc/resolv.conf
> to unwritable by SELinux, and add trusted DNS servers, or set the option
> to strip the AD-bit.
>
>> If that is the only API to be offered, I recommend we patch the
>> applications with the "postfix method" instead and for now limit
>> ourselves with dnssec only if localhost is specified in resolv.conf.
>
> Why? It will never be enough to guarantee what you want. Such a check
> is only a heuristic.

Sorry Carlos,
but I do not understand how you can claim that checking resolv.conf for 
the address "is only heuristic" and then claim that applications can 
blindly trust the system is configured right.

Applications can't assume the system is using a secure DNS unless you 
have a "new flag" they can check somewhere.

Apparently on the glibc side you haven't thought how applications 
developers will have to behave, let me try to summarize the thinking on 
the proponents side.

First of all application developers cannot mandate what glibc version is 
in use so they can't just trust they are running on a new glibc version 
unless there is something they can check that will positively tell them 
that yes this *is* a new enough glibc version and they can start 
considering trusting it (1).

This means either a new function call they can be compiled against or an 
existing API need to return a value no other previous libc (not just 
glibc) ever returned.

This is step one to even consider trusting libc data wrt DNSSEC relevant 
information, if I can't check at runtime whether libc is trustworthy I 
simply can't trust it.

Second comes the problem of how do the application know whether the 
system is configured correctly or not. The application again cannot just 
assume the user properly configured the system, because the vast 
majority of systems out there is simply not.

And, as you said, checking resolv.conf is useless, simply because the 
application has no way to know what was the status of resolv.conf *when 
it was read by glibc*, that is, unless glibc exposes an API that tells 
the applications that yes, it has been told by the admin to use this 
specific nameserver and that nameserver has been marked as trusted (for 
DNSSEC purposes) by the admin (2).

IMHO, the straightforward option to go about it would be to have a a 
trusted_nameserver option that would tell glibc that the system was 
positively configured with an actually trusted DNS. This option could be 
bare and consider only 127.0.0.1 as trusted and strip AD bits if 
localhost fails to provide DNS service (glibc would still fallback to 
consulting nameserver(s) but not trust them).

Or it could be qualified with IP address of DNS servers that can be 
trusted. This would be useful for some cases, like containers were you 
want a single trusted nameserver on the host and the network namespace 
is configured in unison with resolv.conf to make sure applications 
contact the single trusted nameeserver running on the host (it just 
doesn't look like it is running on 127.0.0.1, but it effectively is).

The trusted_nameserver option (with API to expose it was set) easily 
summarizes (1) and (2) in one shot for applications. Moreover it is an 
option that other resolver libraries like c-ares can also adopt so 
applications across the board can use a single indicator and similar 
APIs and behaviors to handle this problem. This would create a system 
easy to understand, maintain and verify. With a single option to deal 
with, available across any resolver library that reads the *system* 
resolv.conf file.

Now I hope this summarize the thinking of most of the people that asked 
to do something about glibc's resolver and DNSSEC. The small details 
about option names can be discussed but point 1 and 2 about the ability 
of an application to check for trust are paramount. If those guarantees 
cannot provided via glibc then applications simply cannot trust glibc 
directly and need another way. We fear we'll see balkanization of the 
landscape with each application doing its own thing and a nightmare for 
administrators, instead of a single check and option they would now have 
to check how each individual application decided to handle resolving 
DNSSEC ... if they (apps *and* admins) bother at all.

All that said ...

Of course we also have one last option. We (system integrators) can 
still use an option in resolv.conf whether glibc likes it or not, 
instruct applications to check if resolv.conf have that option, and then 
do our best to assure them that when the option is set there is an 
active component that locks down the system and prevents modifications 
to resolv.conf by other parties. This is doable, but requires 
applications to do the unreliable check you mentioned above, and then 
call themselves res_[n]init() and hope that (g)libc will re-read the 
configuration file (it is not clear to me that calling it explicitly 
will always cause a re-read, the man page does not state what happens if 
res_[n]init() is called a second time).

I would prefer if glibc (and all other libraries) gave this information 
to applications themselves, as it would be more efficient. The "out of 
libc" method causes resolv.conf to be re-read 3 times which is a burden 
for short lived processes but is better than not trusting glibc and 
having applications implement their own crypto or have a dozen different 
methods to "configure" DNSSEC.


HTH,
Simo.

-- 
Simo Sorce * Red Hat, Inc * New York