This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] support for trusted validating resolver configuration

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.

Hi Pavel,

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]