This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] support for trusted validating resolver configuration
- From: Florian Weimer <fweimer at redhat dot com>
- To: Pavel Simerda <psimerda at redhat dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Cc: Tomas Hozza <thozza at redhat dot com>, Petr Spacek <pspacek 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: Mon, 01 Dec 2014 16:06:34 +0100
- 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>
On 11/18/2014 01:40 PM, Pavel Simerda wrote:
* Applications can rely on the AD flag coming from the library.
- It's either cleared out or it comes from a trusted validating resolver.
I have looked at the situation, I think there are actually two goals here.
(1) Prevent updating the nss_dns configuration from untrusted sources
(such as DHCP).
(2) The AD flag matter.
I think (1) is a separate issue because there are so many things that
can unexpectedly edit /etc/resolv.conf, essentially taking a trust,
local validating resolver (whether recursive or not) out of the picture.
It's better to consider (2) because that part is really complex. (I
firmly believe we should in no way encourage applications to alter
behavior on the AD bitâwe did this with HTTP, and made encrypting HTTP
opportunistically more difficult.) But the nice thing is that if there
is a foolproof way to lock a system to a trusted resolver, then the
correctness of the AD bit matters less (in the sense that you can be
sure that you receive DNS data at the security level specified by
relevant zone operators).
* Backwards compatibility for free.
- Supporting software writes both resolv.conf and resolv-secure.conf and
reads resolv-secure.conf falling back to resolv.conf when missing.
- Other software writes resolv.conf (thus won't overwrite
resolv-secure.conf) and reads resolv.conf.
I fear this might be overly optimistic because if updates to
/etc/resolv.conf are not inhibited in another way, these legacy
applications would still send queries to the wrong resolver, and use the
wrong search path.
* Easy to support in dynamic configuration tools like dnssec-trigger.
- The tool simply stores its resolv.conf somewhere in /run and creates
symlinks /etc/resolv.conf and /etc/resolv-secure.conf.
- Any other tools will immediatly learn where the data comes from by
checking the symlink target and act accordingly.
Note that some parts of systemd assume that they own the
/etc/resolv.conf symbolic link, so this may or may not work in practice.
For goal (1), there is also the question where the contents of
/etc/resolv-secure.conf will come from. Obviously, DHCP is out.
Florian Weimer / Red Hat Product Security