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 11/16/2015 08:18 PM, Zack Weinberg wrote:
> On 11/14/2015 12:25 PM, Rich Felker wrote:
>> On Tue, Nov 10, 2015 at 08:47:22PM -0500, Zack Weinberg wrote:
>>> On 11/04/2015 03:44 PM, Carlos O'Donell wrote:
>>>> Community,
>>>>
>>>> I have written up a summary of the mailing list discussions
>>>> surrounding DNSSEC and the enhancements required to better
>>>> support it in glibc.
>>>>
>>>> https://sourceware.org/glibc/wiki/DNSSEC
>>>>
>>>> Any thoughts or comments would be much appreciated.
>>>
>>> (I am not a DNS nerd, but I *am* a security nerd.)
>>>
>>> The conversation so far has convinced me of something I've suspected for
>>> a while: The nameservers configured in /etc/resolv.conf *cannot* be
>>> trusted - not even 127.0.0.1.  The only approach that seems viable to me
>>> is to scrap the idea of outsourcing DNSSEC validation to a local DNS server.
>>
>> Why can't 127.0.0.1 be trusted? It runs in essentially the same
>> privilege domain as the nscd. If resolv.conf is misconfigured this is
>> a broken system installation and in general glibc cannot protect you
>> from that.
> 
> Don't you see that the entire rest of this thread demonstrates that
> trying to eliminate all the "broken things distros and dhcp client
> software are doing" is a lost cause?

Calling things a "lost cause" is not an objective technical evaluation
of the present situation. I do not believe we are in an unfixable scenario.
However, you will find that users are going to have to choose between
DNSSEC integrity and some badly designed ISV software that modifies /etc/resolv.conf.
 
> But even if we *could* be sure that resolv.conf had not been changed out
> from under our feet, that wouldn't be good enough, because we have no
> way of knowing whether the local recursive resolver actually implements
> DNSSEC validation.  It would be perfectly possible for someone to slot
> in a local resolver that sets the AD bit on *every response* - and I
> fully expect people to do that exact thing, for the same reasons that
> they love stubbing out TLS certificate validation.

How is this any different than all other forms of system misconfiguration?

> Using nscd avoids that problem because glibc controls the code on both
> sides of /var/run/nscd/socket.  (Yes, I know about unscd.)  In
> particular, we can be confident that there are no configuration knobs
> that produce insecure behavior when frobbed.  And, /etc/nscd.conf *can*
> be in a different privilege domain than /etc/resolv.conf - don't even
> need SELinux for that, all it takes is some groups.

I expect the caching aspects of nscd to conflict with site requirements
such that we will need a distinct solution for DNSSEC.

Cheers,
Carlos.


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