This is the mail archive of the libc-alpha@sourceware.org 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: Building consensus over DNSSEC enhancements to glibc.


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


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