This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] support for trusted validating resolver configuration
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Pavel Simerda <psimerda at redhat dot com>
- Cc: Petr Spacek <pspacek at redhat dot com>, libc-alpha <libc-alpha at sourceware dot org>, Tomas Hozza <thozza at redhat dot com>, Alexandre Oliva <aoliva at redhat dot com>, siddhesh at redhat dot com, schwab at suse dot de, neleai at seznam dot cz
- Date: Thu, 11 Jun 2015 21:41:19 -0400
- Subject: Re: [RFC] support for trusted validating resolver configuration
- Authentication-results: sourceware.org; auth=none
- References: <1593405040 dot 320240 dot 1416314424126 dot JavaMail dot zimbra at redhat dot com> <55799B28 dot 309 at redhat dot com> <5579A452 dot 1010308 at redhat dot com> <5579A8E9 dot 3090106 at redhat dot com> <1265145710 dot 8137389 dot 1434040686212 dot JavaMail dot zimbra at redhat dot com>
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.
Nothing prevents Network Manager from maintaining a list of
trusted DNS servers the user has entered by hand, and using those
instead of what is provided via DHCP.
Your focus appears to be to fix an unfixable situation, you are
already on an untrusted network. 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.
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. This way if Network Manager knows it is in a "public"
network 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, 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.
Cheers,
Carlos.