[RFC] support for trusted validating resolver configuration

  Hello all,

the trusted and untrusted resolver configuration is still an outstanding
issue for us. We are looking for a way to configure a list of trusted
name servers that can be used for validation. In most cases this would
be simply "localhost" or "127.0.0.1" where a local valdating resolver
would be other scenarios could be supported as well.

One way to achieve that is an additional directive written in
/etc/resolv.conf that would say the name servers are to be trusted, another
is to have an separate directive to actually list the trusted nameservers.

I became interested in a different way that doesn't affect /etc/resolv.conf
which is written and read by many security unaware tools. That is to create
a special version of the file just for security aware tools. For now I'm
using the name /etc/resolv-secure.conf.

Goals:

 * Applications can rely on the AD flag coming from the library.
    - It's either cleared out or it comes from a trusted validating resolver.

Solution:

 * When /etc/resolv-secure.conf exists, it is used instead of /etc/resolv.conf
   and all name servers are trusted for DNSSEC validation. Queries are sent
   with AD flag set, answers are passed to the application without changing
   the flag.

 * When /etc/resolv-secure.conf doesn't exist, /etc/resolv.conf is used and
   no servers are trusted for DNSSEC validation. Queries are preferably sent
   without the AD flag and the AD flags in responses are cleared out before
   passing them to the application.

(Corner cases like unreadable /etc/resolv-secure.conf are yet to be defined.)

A proof of concept patch is attached. I tried it and it worked for me. I used
netresolve[1] tools to perform the testing.

[1] https://sourceware.org/git/?p=netresolve.git;a=blob;f=README;hb=HEAD

Advantages:

 * Simple logic, based on the existance of /etc/resolv-secure.conf.

 * Backwards compatibility for free.
    - Supporting software writes both resolv.conf and resolv-secure.conf and
      reads resolv-secure.conf falling back to resolv.conf when missing.
    - Other software writes resolv.conf (thus won't overwrite
      resolv-secure.conf) and reads resolv.conf.

 * Format of /etc/resolv-secure.conf is identical to that of /etc/resolv.conf.
    - It is easy to update security aware software to use the new file and
      fallback to the old one.

 * Easy to support in dynamic configuration tools like dnssec-trigger.
    - The tool simply stores its resolv.conf somewhere in /run and creates
      symlinks /etc/resolv.conf and /etc/resolv-secure.conf.
    - Any other tools will immediatly learn where the data comes from by
      checking the symlink target and act accordingly.

Disadvantages:

 * A new file to look into for DNS configuration.

Resources:

 * fedora: glibc ticket: https://bugzilla.redhat.com/show_bug.cgi?id=1164339
 * fedora: c-ares ticket: https://bugzilla.redhat.com/show_bug.cgi?id=1164337
 * fedora: dnssec-trigger ticket: https://bugzilla.redhat.com/show_bug.cgi?id=1165126

Cheers,

Pavel
  

On 11/18/2014 01:40 PM, Pavel Simerda wrote:
> Goals:
>
>   * Applications can rely on the AD flag coming from the library.
>      - It's either cleared out or it comes from a trusted validating resolver.

Hi Pavel,

I have looked at the situation, I think there are actually two goals here.

(1) Prevent updating the nss_dns configuration from untrusted sources 
(such as DHCP).

(2) The AD flag matter.

I think (1) is a separate issue because there are so many things that 
can unexpectedly edit /etc/resolv.conf, essentially taking a trust, 
local validating resolver (whether recursive or not) out of the picture.

It's better to consider (2) because that part is really complex.  (I 
firmly believe we should in no way encourage applications to alter 
behavior on the AD bit—we did this with HTTP, and made encrypting HTTP 
opportunistically more difficult.)  But the nice thing is that if there 
is a foolproof way to lock a system to a trusted resolver, then the 
correctness of the AD bit matters less (in the sense that you can be 
sure that you receive DNS data at the security level specified by 
relevant zone operators).

>   * Backwards compatibility for free.
>      - Supporting software writes both resolv.conf and resolv-secure.conf and
>        reads resolv-secure.conf falling back to resolv.conf when missing.
>      - Other software writes resolv.conf (thus won't overwrite
>        resolv-secure.conf) and reads resolv.conf.

I fear this might be overly optimistic because if updates to 
/etc/resolv.conf are not inhibited in another way, these legacy 
applications would still send queries to the wrong resolver, and use the 
wrong search path.

>   * Easy to support in dynamic configuration tools like dnssec-trigger.
>      - The tool simply stores its resolv.conf somewhere in /run and creates
>        symlinks /etc/resolv.conf and /etc/resolv-secure.conf.
>      - Any other tools will immediatly learn where the data comes from by
>        checking the symlink target and act accordingly.

Note that some parts of systemd assume that they own the 
/etc/resolv.conf symbolic link, so this may or may not work in practice.

For goal (1), there is also the question where the contents of 
/etc/resolv-secure.conf will come from.  Obviously, DHCP is out.

Florian
  

----- Original Message -----
> From: "Florian Weimer" <fweimer@redhat.com>
> To: "Pavel Simerda" <psimerda@redhat.com>, "libc-alpha" <libc-alpha@sourceware.org>
> Cc: "Tomas Hozza" <thozza@redhat.com>, "Petr Spacek" <pspacek@redhat.com>, "Alexandre Oliva" <aoliva@redhat.com>,
> siddhesh@redhat.com, schwab@suse.de, neleai@seznam.cz
> Sent: Monday, December 1, 2014 4:06:34 PM
> Subject: Re: [RFC] support for trusted validating resolver configuration
> 
> On 11/18/2014 01:40 PM, Pavel Simerda wrote:
> > Goals:
> >
> >   * Applications can rely on the AD flag coming from the library.
> >      - It's either cleared out or it comes from a trusted validating
> >      resolver.
> 
> Hi Pavel,
> 
> I have looked at the situation, I think there are actually two goals here.

Thanks a lot!

For the record, we're talking about the following proposal:

https://sourceware.org/ml/libc-alpha/2014-11/msg00426.html

Basically the proposal shouldn't be read as a cure for all DNSSEC related
issues but rather as an important building block. Technical notes follow.

> (1) Prevent updating the nss_dns configuration from untrusted sources
> (such as DHCP).

The proposal doesn't talk about nss_dns because nsswitch modules don't
currently provide any security information for the results. Instead it
is about the resolver providing API functions like res_query that return
a complete DNS answer including the AD flag that actually carries such
information.

The proposal also recognizes the need to use dynamically obtained data (like
those from DHCP) in the resolver configuration in order to access local
resources and to use the network infrastructure effectively. 

Therefore the proposal doesn't assume a restricted environment that would
avoid using resolvers not trusted for validation. As a result, it is useful
in all sorts of setups and when its basic assumptions (see later) are met,
it provides universal guarantees for libraries and applications.

> (2) The AD flag matter.
>
> I think (1) is a separate issue because there are so many things that
> can unexpectedly edit /etc/resolv.conf,

The proposal provides the same guarantees whether /etc/resolv.conf is guarded
from being replaced/rewritten or not.

> essentially taking a trust,
> local validating resolver (whether recursive or not) out of the picture.

One of the main features of the proposal is that /etc/resolv.conf contents
don't define the trusted validating resolver.

> It's better to consider (2) because that part is really complex.  (I
> firmly believe we should in no way encourage applications to alter
> behavior on the AD bit

As far as I understand, the AD flag is the standard way[1][2] the trusted
validator signals that the returned data is authenticated (using DNSSEC).

[1] http://tools.ietf.org/html/rfc4035#section-3.2.3
[2] http://tools.ietf.org/html/rfc6840#section-5.6

An application that relies on the security level of the data[1][2][3] has
therefore no other choice than directly or indirectly:

1) Derive the authenticity from the *AD flag* when the trusted validator
is contacted using DNS (e.g. via the stub resolver in libc). The proposal
ensures that it is safe to use the AD flag from the stub resolver.

2) Derive the authenticity from *an equivalent of the AD flag* when the
trusted validator is contacted via other means or the application performs
validation itself. The proposal avoids the need to perform the validation
in the application itself (e.g. using libunbound[4]).

Correct me if I'm wrong.

[1] https://tools.ietf.org/html/rfc6698
[2] https://tools.ietf.org/html/rfc4025
[3] https://tools.ietf.org/html/rfc4255
[4] https://unbound.net/documentation/libunbound.html

> But the nice thing is that if there is a foolproof way to lock a system
> to a trusted resolver,

The proposal ensures that for retrieving data from insecure zones, there
is no difference between a trusted validator and any other resolver. For
retrieving data from secure zones, it ensures that an untrusted resolver
cannot spoof the validation data.

In addition to the proposal, the operating system should employ techniques
to maximize the availability of the trusted validator in order to provide
security aware applications with validation data whenever possible as well
as to provide opportunistic(*) security to all applications. We are working
on this in the dnssec-trigger and unbound projects[1] and we appreciate
any feedback.

[1] https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver

(*) Where the opportunity depends on whether the zone is evaluated as signed
using a chain of trust. Please correct me if there's a better term for it.

> then the correctness of the AD bit matters less (in the sense that you can be
> sure that you receive DNS data at the security level specified by
> relevant zone operators).

This is useful for the opportunistic security (as specified above). Security
aware applications still need the AD flag (or an equivalent) to learn the
actual security level. Some data like TLSA[1], IPsec keying material[2] and
SSH key fingerprints[3] can only be used authenticated.

[1] https://tools.ietf.org/html/rfc6698
[2] https://tools.ietf.org/html/rfc4025
[3] https://tools.ietf.org/html/rfc4255

> For goal (1), there is also the question where the contents of
> /etc/resolv-secure.conf will come from. Obviously, DHCP is out.

Looks like I omitted this information in the original posting. Untrusted
sources like DHCP may still be needed to configure the trusted validating
resolver *whose* address ends up in /etc/resolv-secure.conf.

Please treat the following list of situations as an amendment to the proposal:

 * /etc/resolv-secure.conf contains just 127.0.0.1 and we have a locally
   running validating name server. This is part of what dnssec-trigger with
   unbound achieves, but can be done manually as well.

 * In a managed environment /etc/resolv-secure.conf includes the address of
   a validating name server that is securely reachable. This may apply to a
   host with containers or virtual machines, as well as a secure network
   managed by an automated tool.

 * The administrator really knows what he's doing, secures the network on his own,
   and drops the address of a name server in /etc/resolv-secure.conf that will
   be trusted to express the validation result using the AD flag.

Thank you again for finding time to review the proposal. As you see on the mailing
list, it's not easy to get feedback in this area.

Cheers,

Pavel
  

On 12/01/2014 10:51 PM, Pavel Simerda wrote:
> ----- Original Message -----
> > From: "Florian Weimer" <fweimer@redhat.com>
> > To: "Pavel Simerda" <psimerda@redhat.com>, "libc-alpha" <libc-alpha@sourceware.org>
> > Cc: "Tomas Hozza" <thozza@redhat.com>, "Petr Spacek" <pspacek@redhat.com>, "Alexandre Oliva" <aoliva@redhat.com>,
> > siddhesh@redhat.com, schwab@suse.de, neleai@seznam.cz
> > Sent: Monday, December 1, 2014 4:06:34 PM
> > Subject: Re: [RFC] support for trusted validating resolver configuration
> >
> > On 11/18/2014 01:40 PM, Pavel Simerda wrote:
> >> Goals:
> >>
> >>   * Applications can rely on the AD flag coming from the library.
> >>      - It's either cleared out or it comes from a trusted validating
> >>      resolver.
> >
> > Hi Pavel,
> >
> > I have looked at the situation, I think there are actually two goals here.

Hi Pavel.

> Thanks a lot!
>
> For the record, we're talking about the following proposal:
>
> https://sourceware.org/ml/libc-alpha/2014-11/msg00426.html
>
> Basically the proposal shouldn't be read as a cure for all DNSSEC related
> issues but rather as an important building block. Technical notes follow.

I think applications can have only little trust in the information returned
by libc, if the library does not check if the data came from a trusted source,
while passing the AD bit to application.

I agree it is just one of the building blocks.

> > (1) Prevent updating the nss_dns configuration from untrusted sources
> > (such as DHCP).
>
> The proposal doesn't talk about nss_dns because nsswitch modules don't
> currently provide any security information for the results. Instead it
> is about the resolver providing API functions like res_query that return
> a complete DNS answer including the AD flag that actually carries such
> information.
>
> The proposal also recognizes the need to use dynamically obtained data (like
> those from DHCP) in the resolver configuration in order to access local
> resources and to use the network infrastructure effectively.
>
> Therefore the proposal doesn't assume a restricted environment that would
> avoid using resolvers not trusted for validation. As a result, it is useful
> in all sorts of setups and when its basic assumptions (see later) are met,
> it provides universal guarantees for libraries and applications.
>
> > (2) The AD flag matter.
> >
> > I think (1) is a separate issue because there are so many things that
> > can unexpectedly edit /etc/resolv.conf,
>
> The proposal provides the same guarantees whether /etc/resolv.conf is guarded
> from being replaced/rewritten or not.

Yes, since the proposal is expecting a new file /etc/resolv-secure.conf
to be added. We can also restrict the modification of the file using mechanisms
like extended file attributes or SELinux policy.

> > essentially taking a trust,
> > local validating resolver (whether recursive or not) out of the picture.
>
> One of the main features of the proposal is that /etc/resolv.conf contents
> don't define the trusted validating resolver.
>
> > It's better to consider (2) because that part is really complex.  (I
> > firmly believe we should in no way encourage applications to alter
> > behavior on the AD bit
>
> As far as I understand, the AD flag is the standard way[1][2] the trusted
> validator signals that the returned data is authenticated (using DNSSEC).
>
> [1] http://tools.ietf.org/html/rfc4035#section-3.2.3
> [2] http://tools.ietf.org/html/rfc6840#section-5.6
>
> An application that relies on the security level of the data[1][2][3] has
> therefore no other choice than directly or indirectly:
>
> 1) Derive the authenticity from the *AD flag* when the trusted validator
> is contacted using DNS (e.g. via the stub resolver in libc). The proposal
> ensures that it is safe to use the AD flag from the stub resolver.
>
> 2) Derive the authenticity from *an equivalent of the AD flag* when the
> trusted validator is contacted via other means or the application performs
> validation itself. The proposal avoids the need to perform the validation
> in the application itself (e.g. using libunbound[4]).
>
> Correct me if I'm wrong.
>
> [1] https://tools.ietf.org/html/rfc6698
> [2] https://tools.ietf.org/html/rfc4025
> [3] https://tools.ietf.org/html/rfc4255
> [4] https://unbound.net/documentation/libunbound.html

I think you are right and the proposal conforms to AD bit description
and usage in existing RFCs.

> > But the nice thing is that if there is a foolproof way to lock a system
> > to a trusted resolver,
>
> The proposal ensures that for retrieving data from insecure zones, there
> is no difference between a trusted validator and any other resolver. For
> retrieving data from secure zones, it ensures that an untrusted resolver
> cannot spoof the validation data.
>
> In addition to the proposal, the operating system should employ techniques
> to maximize the availability of the trusted validator in order to provide
> security aware applications with validation data whenever possible as well
> as to provide opportunistic(*) security to all applications. We are working
> on this in the dnssec-trigger and unbound projects[1] and we appreciate
> any feedback.
>
> [1] https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
>
> (*) Where the opportunity depends on whether the zone is evaluated as signed
> using a chain of trust. Please correct me if there's a better term for it.

The proposal role should be to ensure that if anyone modifies the /etc/resolv.conf
it will not affect the trust of AD bit if there is resolv-secure.conf. If someone
removes the resolv-secure.conf then there is no way the application can be fooled
by the AD bit set in the response.

I agree that the countermeasures have to be employed by the OS, not the library.

> > then the correctness of the AD bit matters less (in the sense that you can be
> > sure that you receive DNS data at the security level specified by
> > relevant zone operators).
>
> This is useful for the opportunistic security (as specified above). Security
> aware applications still need the AD flag (or an equivalent) to learn the
> actual security level. Some data like TLSA[1], IPsec keying material[2] and
> SSH key fingerprints[3] can only be used authenticated.
>
> [1] https://tools.ietf.org/html/rfc6698
> [2] https://tools.ietf.org/html/rfc4025
> [3] https://tools.ietf.org/html/rfc4255

The goal of the proposal is to make sure the AD bit is not set at all if
trusted validating resolver was not used. Thus making the data not trusted.

The security level specified by zone may affect the trustworthiness of data
only from that zone, but will not affect the AD bit trustworthiness universally.

The proposal improves the situation compared to the current reality when
the AD bit is used blindly by the libc, which makes it hard to trust.

> > For goal (1), there is also the question where the contents of
> > /etc/resolv-secure.conf will come from. Obviously, DHCP is out.
>
> Looks like I omitted this information in the original posting. Untrusted
> sources like DHCP may still be needed to configure the trusted validating
> resolver *whose* address ends up in /etc/resolv-secure.conf.
>
> Please treat the following list of situations as an amendment to the proposal:
>
>  * /etc/resolv-secure.conf contains just 127.0.0.1 and we have a locally
>    running validating name server. This is part of what dnssec-trigger with
>    unbound achieves, but can be done manually as well.
>
>  * In a managed environment /etc/resolv-secure.conf includes the address of
>    a validating name server that is securely reachable. This may apply to a
>    host with containers or virtual machines, as well as a secure network
>    managed by an automated tool.
>
>  * The administrator really knows what he's doing, secures the network on his own,
>    and drops the address of a name server in /etc/resolv-secure.conf that will
>    be trusted to express the validation result using the AD flag.

Right, the content of /etc/resolv-secure.conf should be configured by the
administrator.
The easiest way is to have a locally running validating resolver which ideally uses
nameservers obtained via DHCP to fetch all the information from authoritative
nameservers.
Since it does the validation itself, we can trust the AD bit value.

> Thank you again for finding time to review the proposal. As you see on the mailing
> list, it's not easy to get feedback in this area.
>
> Cheers,
>
> Pavel

Is there any estimate when this could get into the libc?
I think we would really benefit from the support in the future,
considering we are hopefully going to have trusted validating
resolver in Fedora by default.

Thanks!

Tomas
  

On 11/18/2014 07:40 AM, Pavel Simerda wrote:
>  * A new file to look into for DNS configuration.

This is such a major disadvantage that I feel the proposal
should be expanded to consider other alternatives that take
into account whole-system integration issues e.g. local
validating resolver, and how this will work with the variety
of virtualization and isolation technology being employed
today. What will network manager do? How do you define your
policies?

I'm hesitant to commit to anything in glibc without seeing
more discussions with Network Manager, dhcp, and the various
other parts of a distribution stack that need to coordinate
secure and trustworthy DNS support.

Cheers,
Carlos.

Notes:
- Public Fedora Bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1164339
- Fedora discussion on local validating resolver:
https://lists.fedoraproject.org/pipermail/devel/2015-June/210992.html
  

On 11.6.2015 16:28, Carlos O'Donell wrote:
> On 11/18/2014 07:40 AM, Pavel Simerda wrote:
>>  * A new file to look into for DNS configuration.
> 
> This is such a major disadvantage that I feel the proposal
> should be expanded to consider other alternatives that take
> into account whole-system integration issues e.g. local
> validating resolver, and how this will work with the variety
> of virtualization and isolation technology being employed
> today. What will network manager do? How do you define your
> policies?

Do I understand correctly that you are okay with the basic principle but the
configuration format should be improved?

The format and if it should be a separate file (or somewhere else) is
definitely an open question - ideas are more than welcome!

I'm happy to discuss this with all interested parties. Should we move
system-wide discussion to fedora-devel list?

Thank you for your answers!

Petr^2 Spacek

> I'm hesitant to commit to anything in glibc without seeing
> more discussions with Network Manager, dhcp, and the various
> other parts of a distribution stack that need to coordinate
> secure and trustworthy DNS support.
> 
> Cheers,
> Carlos.
> 
> Notes:
> - Public Fedora Bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=1164339
> - Fedora discussion on local validating resolver:
> https://lists.fedoraproject.org/pipermail/devel/2015-June/210992.html
  

On 06/11/2015 11:08 AM, Petr Spacek wrote:
> On 11.6.2015 16:28, Carlos O'Donell wrote:
>> On 11/18/2014 07:40 AM, Pavel Simerda wrote:
>>>  * A new file to look into for DNS configuration.
>>
>> This is such a major disadvantage that I feel the proposal
>> should be expanded to consider other alternatives that take
>> into account whole-system integration issues e.g. local
>> validating resolver, and how this will work with the variety
>> of virtualization and isolation technology being employed
>> today. What will network manager do? How do you define your
>> policies?
> 
> Do I understand correctly that you are okay with the basic principle but the
> configuration format should be improved?

No. I think an additional configuration file should be the last
recourse if we can find no other way to solve this problem.
I would like to see other avenues explored or at the very least
an explanation of why other choices were deemed unacceptable.
Adding yet-another configuration file is the naive and easy choice
that comes with all sorts of other problems, from education,
configuration, and social e.g. network manager might just start
writing duplicate data into /etc/resolv-secure.conf anyway. How
do you plan to stop that? With policy and discussions upstream.

> The format and if it should be a separate file (or somewhere else) is
> definitely an open question - ideas are more than welcome!

At the very least I might conceede a security `options` flag to
/etc/resolf.conf with entirely disables DNS secuirty related pass
through e.g. option insecure-dns.

> I'm happy to discuss this with all interested parties. Should we move
> system-wide discussion to fedora-devel list?

Yes.

Cheers,
Carlos.
  

----- Original Message -----
> From: "Carlos O'Donell" <carlos@redhat.com>
> To: "Petr Spacek" <pspacek@redhat.com>, "Pavel Simerda" <psimerda@redhat.com>, "libc-alpha"
> <libc-alpha@sourceware.org>
> Cc: "Tomas Hozza" <thozza@redhat.com>, "Alexandre Oliva" <aoliva@redhat.com>, siddhesh@redhat.com, schwab@suse.de,
> neleai@seznam.cz
> Sent: Thursday, June 11, 2015 5:27:37 PM
> Subject: Re: [RFC] support for trusted validating resolver configuration
> 
> On 06/11/2015 11:08 AM, Petr Spacek wrote:
> > On 11.6.2015 16:28, Carlos O'Donell wrote:
> >> On 11/18/2014 07:40 AM, Pavel Simerda wrote:
> >>>  * A new file to look into for DNS configuration.
> >>
> >> This is such a major disadvantage that I feel the proposal
> >> should be expanded to consider other alternatives that take
> >> into account whole-system integration issues e.g. local
> >> validating resolver, and how this will work with the variety
> >> of virtualization and isolation technology being employed
> >> today. What will network manager do? How do you define your
> >> policies?
> > 
> > Do I understand correctly that you are okay with the basic principle but
> > the
> > configuration format should be improved?
> 
> No. I think an additional configuration file should be the last
> recourse if we can find no other way to solve this problem.
> I would like to see other avenues explored or at the very least
> an explanation of why other choices were deemed unacceptable.

If I can add my two cents to the discussion. The choice wasn't based
on unacceptability of other solution but on comparison of advantages
and disadvantages of the solutions. But it was from the beginning
meant as a way to open discussions as well.

Other alternatives that were considered:

1) Additional directive saying whether the resolv.conf nameservers
are to be considered trusted for DNSSEC validation.

Disadvantage: A tool might rewrite just nameservers and keep all
unknown directives, jeopardizing DNSSEC trustworthiness.

2) Additional directive specifying one or more nameservers trusted
for DNSSEC validation.

Disadvantage: The format would always just repeat the list of
nameservers as the list of trusted nameservers.

The separate file doesn't have those advantages as it can simply
reside in /etc/resolve-secure.conf, be protected by mandatory
access control from being replaced or rewritten. For compatibility,
/etc/resolv.conf can be a symlink to /etc/resolv-secure.conf.

Thus you (1) avoid duplication of configuration, (2) guard the security
configuration from unauthorized change and (3) keep backwards
compatibility.

> Adding yet-another configuration file is the naive and easy choice
> that comes with all sorts of other problems, from education,
> configuration, and social e.g. network manager might just start
> writing duplicate data into /etc/resolv-secure.conf anyway. How
> do you plan to stop that? With policy and discussions upstream.

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.

Only the administrator or a tool properly instructed by the administrator
should write that file. An example of such a tool is dnssec-trigger that
always uses the local host for a server.

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 format and if it should be a separate file (or somewhere else) is
> > definitely an open question - ideas are more than welcome!
> 
> At the very least I might conceede a security `options` flag to
> /etc/resolf.conf with entirely disables DNS secuirty related pass
> through e.g. option insecure-dns.
> 
> > I'm happy to discuss this with all interested parties. Should we move
> > system-wide discussion to fedora-devel list?
> 
> Yes.
> 
> Cheers,
> Carlos.
> 
>
  

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.
  

On Thu, Jun 11, 2015 at 09:41:19PM -0400, Carlos O'Donell wrote:
> 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.

Agree. I'm with Carlos on all of this.

Rich
  

----- Original Message -----
> From: "Carlos O'Donell" <carlos@redhat.com>
> To: "Pavel Simerda" <psimerda@redhat.com>
> Cc: "Petr Spacek" <pspacek@redhat.com>, "libc-alpha" <libc-alpha@sourceware.org>, "Tomas Hozza" <thozza@redhat.com>,
> "Alexandre Oliva" <aoliva@redhat.com>, siddhesh@redhat.com, schwab@suse.de, neleai@seznam.cz
> Sent: Friday, June 12, 2015 3:41:19 AM
> Subject: 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.

Hi,

Those distribution policies have been correct for ages. Before DNSSEC
was created, noone would question them.

We were looking for a solution where:

1) Application or security library can trust the data from glibc
   resolver including security information.
2) Resolver can provide unauthenticated DNS data when in non-DNSSEC
   mode and the list of recursive name servers is configured by a system
   administrator or an automated tool.
3) Resolver can provide autenticated DNS data when in DNSSEC mode and
   the list of trusted resolvers is provided by the system administrator
   (rarely) or by an automated tool (in most cases giving just 127.0.0.1).

The most important think is that the application never receives autenticated
data that were only verified by an ordinary recursive server. That would
mean an implicit trust in an unauthorized and unexpected DNSSEC validator.

Note that a recursive name server is typically a host on the local network
announced by DHCP while a trusted validator is typically the local machine
which itself is talking to a recursive name server.

The current implementation in glibc doesn't achieve the goals stated above
and doesn't prevent the security problem of implicitly using foreign
recursive name servers as trusted DNSSEC validators.

We have an experimental implementation using '/etc/resolv-secure.conf' that
solves the problem. I'm looking forward to see any alternatives. The issue
has been holding back DNSSEC deployment for long and might cause a lot of
damage.

> Nothing prevents Network Manager from maintaining a list of
> trusted DNS servers

In a non-DNSSEC setup, NetworkManager gathers list of recursive
name servers (not trusted validators) and writes them to
'/etc/resolv.conf' so the resolver can do its job.

In a DNSSEC setup, NetworkManager gathers the very same list of recursive
name servers, (through dnssec-trigger) configures the local trusted DNSSEC
validator (unbound) and (without our fix) writes 'nameserver 127.0.0.1'
to '/etc/resolv.conf'.

In none of the two most common cases above there is any list of trusted DNS
servers to be maintained.

> the user has entered by hand, and using those
> instead of what is provided via DHCP.

NetworkManager accepts the list of recursive name servers (whether from the
user or from DHCP), not the trusted validators. Instead in
NetworkManager/dnssec-trigger setups, the trusted validator is always
'127.0.0.1'.

> Your focus appears to be to fix an unfixable situation,

It may appear so but it definitely isn't. See the definition of goals
at the top of this mail. And we already have an experimental working
solution that works in line with the goals.

> you are already on an untrusted network.

There is a huge difference between using an untrusted recursive name server
and using an untrusted DNSSEC validator. DNSSEC works great with untrusted
recursive name servers but its security is jeopardized by *using them as
DNSSEC validators*.

> 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.

For DNSSEC, all we need is to never implicitly use recursive name servers
as trusted DNSSEC validators. In my opinion, the best way to implement that
is to avoid passing security information from ordinary recursive name
servers (not configured as trusted DNSSEC validators).

> 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.

It is still wrong to use recursive name servers as trusted DNSSEC validators
by default.

> This way if Network Manager knows it is in a "public"
> network

This has nothing to do with public networks. It is wrong to use recursive name
servers as trusted DNSSEC validators unless explicitly stated.

Using a local name server as trusted DNSSEC validator is on the same level as
using a local HTTPS proxy without checking any certificates.

> 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,

No, because DNSSEC doesn't have the concept of trusting a network at all.

> 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.

Sure.

Cheers,

Pavel