Re: Building consensus over DNSSEC enhancements to glibc.

["Carlos O'Donell" <carlos at redhat dot com>]

On 11/16/2015 04:40 AM, Paul Wouters wrote:
> On 11/14/2015 01:22 PM, Carlos O'Donell wrote:
>> On 11/06/2015 04:42 AM, Petr Spacek wrote:
>>> The proposed AD bit stripping was an easy and cheap way to do
>>> this at one place in the system, with central configuration,
>>> which would allow us to eliminate all kinds of weird
>>> re-implementations in applications.
>> 
>> You have it.
>> 
>> Use `options dns-strip-dnssec-ad-bit` until you have NetworkManager
>> running with the right options and a local validating resolver.
>> 
>> I agree with Rich Felker. You must not allow anything to change
>> /etc/resolv.conf that isn't the master process (e.g. resolvconf in
>> Ubuntu) which is in charge of policy.
> 
> That is not a realistic policy. If such a policy resulted in workable
> systems, we would have selinuxed the shit out of /etc/resolv.conf to
> make sure no one could ever edit it.

It is a realistic policy, it just requires work and coordination across
those applications. Doesn't Ubuntu's resolvconf do just this?

Look at:
https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns-resolving

I argue that making /etc/resolv.conf unwritable except by a special
process is exactly the right "next step."

If you disable SELinux then you have an insecure DNSSEC configuration,
or a opportunistically secure configuration as resolvconf tries to prevent
unauthorized applications from wiriting to /etc/resolv.conf (via file
permissions, or inotify/stat monitoring).

Note that in upstream glibc /etc/resolv.conf is read *once* at process
startup and never again. Distributions like Debian/Ubuntu violate this
invariant at their own cost (additional stat) and possibly inconsistent
behaviour as an admin changes the file between internal calls to stub
resolver functions.

> People too often depend on other processes (vpn clients, puppet,
> ansible and what not) that requires them (for stupid reasons we will
> keep telling them to fix) to change resolv.conf.

If you allow those processes to modify /etc/resolv.conf then you have
an insecure DNSSEC configuration.

Can you ever trust such a system to be secure with respect to DNSSEC?
The user of these systems is placing entries into /etc/resolv.conf
which are not under the control of a central policy framework whose
goal is to decide: trusted, untrusted, etc. based on interfaces, time
of day, firewall zone, geolocation etc.

My answer remains the same: glibc is not the place for these flexible
policy decisions. glibc should provide a robust stub resolver that
can interface with a resolver that is tied into the policy framework.

In the "lockdown" scenario we have `options dns-strip-dnssec-ad-bit`
and SELinux to start the system in a secure configuration.

Cheers,
Carlos.