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: [RFC] support for trusted validating resolver configuration


On 06/11/2015 12:38 PM, Pavel Simerda wrote:
> Rewriting of /etc/resolv-secure.conf by an unauthorized tool would be
> an attack on the system's security and should be treated as such, from
> blocking by mandatory access control to reporting as malware or CVE.

Here is were we differ in opinion.

I already consider /etc/resolv.conf to be that file, and only by
administrative authorization should it be written, either by VPN
or by Network manager.

It is the distribution policies that allow untrusted DNS servers
to be added to that list when connecting to untrusted networks.
Nothing prevents Network Manager from maintaining a list of
trusted DNS servers the user has entered by hand, and using those
instead of what is provided via DHCP.

Your focus appears to be to fix an unfixable situation, you are
already on an untrusted network. If anything you need an API to
describe the network trust level e.g. Can I trust the results from
DNS? This way applications will know if the results they have from
any interface are safe.

Until such an API exists I concede that a /etc/resolv.conf option,
say `insecure-dns` could be created to remove all security information
from DNS queries. This way if Network Manager knows it is in a "public"
network it will set `option insecure-dns` in /etc/resolve.conf.

> Of course this is just one way to do it. But I chose it for both ease of
> implementation which is obvious from the submitted patch, and for its
> inherent advantages described above. On the other hand, I will be happy
> to learn about a better solution that will address the same potential
> issues my patch addresses.

The better solution is a higher level API for determining if you can
trust the network, not breaking end-to-end principles by manipulating
returned DNS packets. I concede that we need a middle ground though.

I would still like to see, and haven't seen, a detailed design document
with the specific use cases and concrete applications that are driving
these changes e.g. a wiki page somewhere with a design.

Cheers,
Carlos.




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