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: "Petr Spacek" <pspacek@redhat.com>, "Pavel Simerda" <psimerda@redhat.com>, "libc-alpha"
> <libc-alpha@sourceware.org>
> Cc: "Tomas Hozza" <thozza@redhat.com>, "Alexandre Oliva" <aoliva@redhat.com>, siddhesh@redhat.com, schwab@suse.de,
> neleai@seznam.cz
> Sent: Thursday, June 11, 2015 5:27:37 PM
> Subject: Re: [RFC] support for trusted validating resolver configuration
> 
> On 06/11/2015 11:08 AM, Petr Spacek wrote:
> > On 11.6.2015 16:28, Carlos O'Donell wrote:
> >> On 11/18/2014 07:40 AM, Pavel Simerda wrote:
> >>>  * A new file to look into for DNS configuration.
> >>
> >> This is such a major disadvantage that I feel the proposal
> >> should be expanded to consider other alternatives that take
> >> into account whole-system integration issues e.g. local
> >> validating resolver, and how this will work with the variety
> >> of virtualization and isolation technology being employed
> >> today. What will network manager do? How do you define your
> >> policies?
> > 
> > Do I understand correctly that you are okay with the basic principle but
> > the
> > configuration format should be improved?
> 
> No. I think an additional configuration file should be the last
> recourse if we can find no other way to solve this problem.
> I would like to see other avenues explored or at the very least
> an explanation of why other choices were deemed unacceptable.

If I can add my two cents to the discussion. The choice wasn't based
on unacceptability of other solution but on comparison of advantages
and disadvantages of the solutions. But it was from the beginning
meant as a way to open discussions as well.

Other alternatives that were considered:

1) Additional directive saying whether the resolv.conf nameservers
are to be considered trusted for DNSSEC validation.

Disadvantage: A tool might rewrite just nameservers and keep all
unknown directives, jeopardizing DNSSEC trustworthiness.

2) Additional directive specifying one or more nameservers trusted
for DNSSEC validation.

Disadvantage: The format would always just repeat the list of
nameservers as the list of trusted nameservers.

The separate file doesn't have those advantages as it can simply
reside in /etc/resolve-secure.conf, be protected by mandatory
access control from being replaced or rewritten. For compatibility,
/etc/resolv.conf can be a symlink to /etc/resolv-secure.conf.

Thus you (1) avoid duplication of configuration, (2) guard the security
configuration from unauthorized change and (3) keep backwards
compatibility.

> Adding yet-another configuration file is the naive and easy choice
> that comes with all sorts of other problems, from education,
> configuration, and social e.g. network manager might just start
> writing duplicate data into /etc/resolv-secure.conf anyway. How
> do you plan to stop that? With policy and discussions upstream.

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.

Only the administrator or a tool properly instructed by the administrator
should write that file. An example of such a tool is dnssec-trigger that
always uses the local host for a server.

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 format and if it should be a separate file (or somewhere else) is
> > definitely an open question - ideas are more than welcome!
> 
> At the very least I might conceede a security `options` flag to
> /etc/resolf.conf with entirely disables DNS secuirty related pass
> through e.g. option insecure-dns.
> 
> > I'm happy to discuss this with all interested parties. Should we move
> > system-wide discussion to fedora-devel list?
> 
> Yes.
> 
> Cheers,
> Carlos.
> 
>