Message ID | 1593405040.320240.1416314424126.JavaMail.zimbra@redhat.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 26601 invoked by alias); 18 Nov 2014 12:40:31 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 26588 invoked by uid 89); 18 Nov 2014 12:40:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL, BAYES_00, SPF_HELO_PASS, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx6-phx2.redhat.com Date: Tue, 18 Nov 2014 07:40:24 -0500 (EST) From: Pavel Simerda <psimerda@redhat.com> To: 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 Message-ID: <1593405040.320240.1416314424126.JavaMail.zimbra@redhat.com> In-Reply-To: <756749060.300961.1416308457339.JavaMail.zimbra@redhat.com> Subject: [RFC] support for trusted validating resolver configuration MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_320238_652408452.1416314424125" |
Commit Message
Pavel Simerda
Nov. 18, 2014, 12:40 p.m. UTC
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
Comments
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
From 05583564e627edbe2a8bfea7b28e6ea9732c438e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pavel=20=C5=A0imerda?= <psimerda@redhat.com> Date: Sun, 16 Nov 2014 00:28:04 +0100 Subject: [PATCH] don't blindly trust AD flag, support /etc/resolv-secure.conf --- resolv/res_init.c | 13 ++++++++++++- resolv/res_mkquery.c | 2 ++ resolv/res_query.c | 4 ++++ resolv/resolv.h | 3 ++- 4 files changed, 20 insertions(+), 2 deletions(-) diff --git a/resolv/res_init.c b/resolv/res_init.c index ea133f8..a063b29 100644 --- a/resolv/res_init.c +++ b/resolv/res_init.c @@ -234,7 +234,12 @@ __res_vinit(res_state statp, int preinit) { (line[sizeof(name) - 1] == ' ' || \ line[sizeof(name) - 1] == '\t')) - if ((fp = fopen(_PATH_RESCONF, "rce")) != NULL) { + bool secure = true; + const char *path; +resolvconf: + path = secure ? "/etc/resolv-secure.conf" : _PATH_RESCONF; + + if ((fp = fopen(path, "rce")) != NULL) { /* No threads use this stream. */ __fsetlocking (fp, FSETLOCKING_BYCALLER); /* read the config file */ @@ -426,6 +431,12 @@ __res_vinit(res_state statp, int preinit) { statp->nsort = nsort; #endif (void) fclose(fp); + + if (secure) + statp->trust_ad_flag = true; + } else if (secure) { + secure = false; + goto resolvconf; } if (__builtin_expect(statp->nscount == 0, 0)) { statp->nsaddr.sin_addr = inet_makeaddr(IN_LOOPBACKNET, 1); diff --git a/resolv/res_mkquery.c b/resolv/res_mkquery.c index 1635e6a..f89935d 100644 --- a/resolv/res_mkquery.c +++ b/resolv/res_mkquery.c @@ -143,6 +143,8 @@ res_nmkquery(res_state statp, hp->opcode = op; hp->rd = (statp->options & RES_RECURSE) != 0; hp->rcode = NOERROR; + if (statp->trust_ad_flag) + hp->ad = 1; cp = buf + HFIXEDSZ; buflen -= HFIXEDSZ; dpp = dnptrs; diff --git a/resolv/res_query.c b/resolv/res_query.c index e4ee2a6..b1edc88 100644 --- a/resolv/res_query.c +++ b/resolv/res_query.c @@ -242,6 +242,10 @@ __libc_res_nquery(res_state statp, /* __libc_res_nsend might have reallocated the buffer. */ hp = (HEADER *) *answerp; + /* Clear untrusted AD flag. */ + if (!statp->trust_ad_flag) + hp->ad = 0; + /* We simplify the following tests by assigning HP to HP2 or vice versa. It is easy to verify that this is the same as ignoring all tests of HP or HP2. */ diff --git a/resolv/resolv.h b/resolv/resolv.h index 53c3bba..1b51e5c 100644 --- a/resolv/resolv.h +++ b/resolv/resolv.h @@ -117,7 +117,8 @@ struct __res_state { unsigned ndots:4; /* threshold for initial abs. query */ unsigned nsort:4; /* number of elements in sort_list[] */ unsigned ipv6_unavail:1; /* connecting to IPv6 server failed */ - unsigned unused:23; + unsigned trust_ad_flag:1; /* trust AD flag from the server */ + unsigned unused:22; struct { struct in_addr addr; u_int32_t mask; -- 1.8.5.5