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: Paul Wouters <pwouters at redhat dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Simo Sorce <simo at redhat dot com>, Petr Spacek <pspacek at redhat dot com>, libc-alpha at sourceware dot org
- Date: Tue, 17 Nov 2015 21:35:30 -0500
- Subject: Re: Building consensus over DNSSEC enhancements to glibc.
- Authentication-results: sourceware.org; auth=none
- References: <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> <564AD51D dot 4040100 at redhat dot com> <564AE333 dot 9090200 at redhat dot com> <564B7A42 dot 6050603 at redhat dot com> <564BD6E6 dot 5040506 at redhat dot com> <20151118020428 dot GJ3818 at brightrain dot aerifal dot cx> <564BE225 dot 2060900 at redhat dot com>
On Wed, Nov 18, 2015 at 11:27:49AM +0900, Paul Wouters wrote:
> On 11/18/2015 11:04 AM, Rich Felker wrote:
>
> > Obviously glibc can't set policy for NetworkManager, but I do not
> > think NM should offer such functionality; it's inherently unsafe. I
> > would almost say we should go so far as ignoring any 'trusted' flag
> > unless the only nameserver is 127.0.0.1, but I can imagine valid
> > setups where a virtual network interface with a different address is
> > used to route queries to a particular server on the same physical
> > host.
>
> If you have a rack of servers you don't want to run a resolver on
> all of them. You trust the network and the network provides a DNS
> server.
>
> There are other reasons too for a "trusted network" feature in NM
> (similar to the Windows "zones" concept really)
>
> For instance to dictate the behaviour of changing the search
> domains. Yesterday from a cafe, I used "ssh bofh" which ended up
> getting matched to the hotspot wildcard record _and_ was running
> ssh, so I got a big warning about something nasty is happening. But
> sometimes this functionality is needed. I believe NM needs to have a
> setting where a user can "trust" the network. This is not something
> that we can automate. So when I join the "redhat" network, I should
> be able to mark it trusted. When I join starbucks it won't be, even
> if I had the WPA password to join the network. But this is another
> problem out of scope for this discussion. But that is why I believe
> NM needs this user-driven concept of "trusted network".
The smarter approach is to just always treat all networks as
untrusted. Even if they're intended to be trusted, trusting them in
ways you don't need to greatly expands the impact of any compromise.
Do you really want a compromised host somewhere on your network (which
is able to do arp poisoning and thereby fake dns results) to be able
to make you accept a forged certificate via forged TLSA results? You
can still use a centralized cache on your network but do the actual
signature verifications on the endpoint.
Rich