This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Building consensus over DNSSEC enhancements to glibc.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Paul Wouters <pwouters at redhat dot com>, Rich Felker <dalias at libc dot org>, Simo Sorce <simo at redhat dot com>
- Cc: Petr Spacek <pspacek at redhat dot com>, libc-alpha at sourceware dot org
- Date: Tue, 17 Nov 2015 02:19:57 -0500
- Subject: Re: Building consensus over DNSSEC enhancements to glibc.
- Authentication-results: sourceware.org; auth=none
- References: <563CED63 dot 1070201 at redhat dot com> <20151106182835 dot GC3818 at brightrain dot aerifal dot cx> <563D0953 dot 9020707 at redhat dot com> <56407C19 dot 2080906 at redhat dot com> <20151109180310 dot GO3818 at brightrain dot aerifal dot cx> <5649A3F3 dot 2060309 at redhat dot com> <20151116161642 dot GQ3818 at brightrain dot aerifal dot cx> <564A0FED dot 9010408 at redhat dot com> <20151116181740 dot GS3818 at brightrain dot aerifal dot cx> <564A1E3E dot 5090703 at redhat dot com> <20151116182322 dot GU3818 at brightrain dot aerifal dot cx> <564AB3F9 dot 4020404 at redhat dot com> <564AC146 dot 1040305 at redhat dot com>
On 11/17/2015 12:55 AM, Paul Wouters wrote:
>> Optionally NetworkManager via resolvconf (coordinating
>> /etc/resolv.conf changes) could set the option if only one insecure
>> public network was connected to the system.
>
> So indeed, this is an insecure solution. One write to
> /etc/resolv.conf and all trusted applications are compromised.
> Applications like gpg or ssh or openpgpkey-milter or even browsers
> checking TLSA records should not bet their security on this.
A system configuration is as secure as the servers in the trusted
/etc/resolv.conf file. If you want secure DNSSEC then set /etc/resolv.conf
to unwritable by SELinux, and add trusted DNS servers, or set the option
to strip the AD-bit.
> If that is the only API to be offered, I recommend we patch the
> applications with the "postfix method" instead and for now limit
> ourselves with dnssec only if localhost is specified in resolv.conf.
Why? It will never be enough to guarantee what you want. Such a check
is only a heuristic.
If you want something more sane we could make a synthetic hwcap bit
like we did for Xen's "nosegneg" and use that to alter the behaviour
of the stub resolver. This gives you something which would allow you
to lock down the called recursive resolver from the very first userspace
process. It could also be disabled on a per-process basis if you had
a kernel interface for it. We have also had a thread local storage
synthetic hwcap bit when we transitioned to using that feature, so
there is some precedent.
So you'd have:
(a) New synthetic hwcap bit "local-validating-resolver" which forces
glibc to only talk to 127.0.0.1 from the very first userspace process.
(b) New options flag "dns-strip-dnssec-ad-bit" which forces glibc to
remove AD-bit data.
Mix-and-match.
Cheers,
Carlos.