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: Rich Felker <dalias at libc dot org>
- To: Petr Spacek <pspacek at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Tue, 10 Nov 2015 12:49:23 -0500
- Subject: Re: Building consensus over DNSSEC enhancements to glibc.
- Authentication-results: sourceware.org; auth=none
- References: <563A6E40 dot 9040508 at redhat dot com> <20151105012328 dot GU8645 at brightrain dot aerifal dot cx> <563C760E dot 4060107 at redhat dot com> <20151106175956 dot GA3818 at brightrain dot aerifal dot cx> <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> <5641C454 dot 3030309 at redhat dot com>
On Tue, Nov 10, 2015 at 11:17:56AM +0100, Petr Spacek wrote:
> On 9.11.2015 19:03, Rich Felker wrote:
> > On Mon, Nov 09, 2015 at 11:57:29AM +0100, Petr Spacek wrote:
> >> One of reasons why 'nameserver 127.0.0.1' only cannot work are systems which
> >> boot from network. Imagine that the system is booting so it does not
> >> necessarily have local resolver running (yet) but the system might need to
> >> mount NFS share with / from somewhere, probably from a NFS server which is
> >> identified by DNS name.
> >
> > That works perfectly well. You simply configure it to use the
> > nameservers from dhcp as the upstream sources for the nameserver
> > running on localhost. All this requires is changing your dhcp client
> > scripts to store the nameservers somewhere other than resolv.conf and
> > notify the local nameserver to use them. The difference from normal
> > dhcp setups is that it's secure against fake/malicious nameservers. If
> > the dhcp-provided nameservers produce fake records, the signatures
> > won't match (or won't be present) ansd they won't be used. In that
> > case the local nameserver can try to fallback to known upstream
> > sources or doing its own recursion if desired; otherwise all lookups
> > just fail.
>
> This can work in theory but you would have to have whole DNSSEC
> validator/crypto stack in the init ramdisk, which may not be an option.
That's only the case if you need DNS before the real filesystem comes
up, for instance if you'll be obtaining the root fs from the network.
In that case you already need at least some sort of cryptographic
validation (albeit maybe just a static list of acceptable
cryptographic hashes) in the initrd. Otherwise you have a trivial
arbitrary code execution vulnerability.
> As Simo said, failing safe is the an important principle in security land so
> saying 'that should not happen' is not good enough.
>
> What would be an acceptable way to implement this in a fail-safe way?
What specifically is "this"?
Rich