Re: [RFC] support for trusted validating resolver configuration

[Pavel Simerda <psimerda at redhat dot com>]

----- Original Message -----
> From: "Carlos O'Donell" <carlos@redhat.com>
> To: "Pavel Simerda" <psimerda@redhat.com>
> Cc: "Petr Spacek" <pspacek@redhat.com>, "libc-alpha" <libc-alpha@sourceware.org>, "Tomas Hozza" <thozza@redhat.com>,
> "Alexandre Oliva" <aoliva@redhat.com>, siddhesh@redhat.com, schwab@suse.de, neleai@seznam.cz
> Sent: Friday, June 12, 2015 3:41:19 AM
> Subject: Re: [RFC] support for trusted validating resolver configuration
> 
> On 06/11/2015 12:38 PM, Pavel Simerda wrote:
> > Rewriting of /etc/resolv-secure.conf by an unauthorized tool would be
> > an attack on the system's security and should be treated as such, from
> > blocking by mandatory access control to reporting as malware or CVE.
> 
> Here is were we differ in opinion.
> 
> I already consider /etc/resolv.conf to be that file, and only by
> administrative authorization should it be written, either by VPN
> or by Network manager.
> 
> It is the distribution policies that allow untrusted DNS servers
> to be added to that list when connecting to untrusted networks.

Hi,

Those distribution policies have been correct for ages. Before DNSSEC
was created, noone would question them.

We were looking for a solution where:

1) Application or security library can trust the data from glibc
   resolver including security information.
2) Resolver can provide unauthenticated DNS data when in non-DNSSEC
   mode and the list of recursive name servers is configured by a system
   administrator or an automated tool.
3) Resolver can provide autenticated DNS data when in DNSSEC mode and
   the list of trusted resolvers is provided by the system administrator
   (rarely) or by an automated tool (in most cases giving just 127.0.0.1).

The most important think is that the application never receives autenticated
data that were only verified by an ordinary recursive server. That would
mean an implicit trust in an unauthorized and unexpected DNSSEC validator.

Note that a recursive name server is typically a host on the local network
announced by DHCP while a trusted validator is typically the local machine
which itself is talking to a recursive name server.

The current implementation in glibc doesn't achieve the goals stated above
and doesn't prevent the security problem of implicitly using foreign
recursive name servers as trusted DNSSEC validators.

We have an experimental implementation using '/etc/resolv-secure.conf' that
solves the problem. I'm looking forward to see any alternatives. The issue
has been holding back DNSSEC deployment for long and might cause a lot of
damage.

> Nothing prevents Network Manager from maintaining a list of
> trusted DNS servers

In a non-DNSSEC setup, NetworkManager gathers list of recursive
name servers (not trusted validators) and writes them to
'/etc/resolv.conf' so the resolver can do its job.

In a DNSSEC setup, NetworkManager gathers the very same list of recursive
name servers, (through dnssec-trigger) configures the local trusted DNSSEC
validator (unbound) and (without our fix) writes 'nameserver 127.0.0.1'
to '/etc/resolv.conf'.

In none of the two most common cases above there is any list of trusted DNS
servers to be maintained.

> the user has entered by hand, and using those
> instead of what is provided via DHCP.

NetworkManager accepts the list of recursive name servers (whether from the
user or from DHCP), not the trusted validators. Instead in
NetworkManager/dnssec-trigger setups, the trusted validator is always
'127.0.0.1'.

> Your focus appears to be to fix an unfixable situation,

It may appear so but it definitely isn't. See the definition of goals
at the top of this mail. And we already have an experimental working
solution that works in line with the goals.

> you are already on an untrusted network.

There is a huge difference between using an untrusted recursive name server
and using an untrusted DNSSEC validator. DNSSEC works great with untrusted
recursive name servers but its security is jeopardized by *using them as
DNSSEC validators*.

> If anything you need an API to
> describe the network trust level e.g. Can I trust the results from
> DNS? This way applications will know if the results they have from
> any interface are safe.

For DNSSEC, all we need is to never implicitly use recursive name servers
as trusted DNSSEC validators. In my opinion, the best way to implement that
is to avoid passing security information from ordinary recursive name
servers (not configured as trusted DNSSEC validators).

> Until such an API exists I concede that a /etc/resolv.conf option,
> say `insecure-dns` could be created to remove all security information
> from DNS queries.

It is still wrong to use recursive name servers as trusted DNSSEC validators
by default.

> This way if Network Manager knows it is in a "public"
> network

This has nothing to do with public networks. It is wrong to use recursive name
servers as trusted DNSSEC validators unless explicitly stated.

Using a local name server as trusted DNSSEC validator is on the same level as
using a local HTTPS proxy without checking any certificates.

> it will set `option insecure-dns` in /etc/resolve.conf.
> 
> > Of course this is just one way to do it. But I chose it for both ease of
> > implementation which is obvious from the submitted patch, and for its
> > inherent advantages described above. On the other hand, I will be happy
> > to learn about a better solution that will address the same potential
> > issues my patch addresses.
> 
> The better solution is a higher level API for determining if you can
> trust the network,

No, because DNSSEC doesn't have the concept of trusting a network at all.

> not breaking end-to-end principles by manipulating
> returned DNS packets. I concede that we need a middle ground though.
> 
> I would still like to see, and haven't seen, a detailed design document
> with the specific use cases and concrete applications that are driving
> these changes e.g. a wiki page somewhere with a design.

Sure.

Cheers,

Pavel