From patchwork Thu Nov 19 06:19:30 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carlos O'Donell X-Patchwork-Id: 9737 Received: (qmail 26187 invoked by alias); 19 Nov 2015 06:20:00 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 26170 invoked by uid 89); 19 Nov 2015 06:19:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Subject: Re: Building consensus over DNSSEC enhancements to glibc. To: Simo Sorce , Paul Wouters , Rich Felker References: <563CED63.1070201@redhat.com> <20151106182835.GC3818@brightrain.aerifal.cx> <563D0953.9020707@redhat.com> <56407C19.2080906@redhat.com> <20151109180310.GO3818@brightrain.aerifal.cx> <5649A3F3.2060309@redhat.com> <20151116161642.GQ3818@brightrain.aerifal.cx> <564A0FED.9010408@redhat.com> <20151116181740.GS3818@brightrain.aerifal.cx> <564A1E3E.5090703@redhat.com> <20151116182322.GU3818@brightrain.aerifal.cx> <564AB3F9.4020404@redhat.com> <564AC146.1040305@redhat.com> <564AD51D.4040100@redhat.com> <564B3FA7.8010100@redhat.com> Cc: Petr Spacek , libc-alpha@sourceware.org From: "Carlos O'Donell" X-Enigmail-Draft-Status: N1110 Message-ID: <564D69F2.7080904@redhat.com> Date: Thu, 19 Nov 2015 01:19:30 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <564B3FA7.8010100@redhat.com> On 11/17/2015 09:54 AM, Simo Sorce wrote: > I would prefer if glibc (and all other libraries) gave this > information to applications themselves, as it would be more > efficient. The "out of libc" method causes resolv.conf to be re-read > 3 times which is a burden for short lived processes but is better > than not trusting glibc and having applications implement their own > crypto or have a dozen different methods to "configure" DNSSEC. I believe the following answers all of the questions in your email, and resolves the use cases you brought forward. If I missed one, please provide it again and I'll see what I can do. I think that defaulting to stripping the AD-bit *and* providing a way for an application to know which resolv.conf option was set at startup would allow the application to know the following: * Assume DNSSEC AD-bit untrusted by default in glibc. - Modern glibc will strip AD-bit by default without `options: dnssec-enforced` specified in /etc/resolv.conf - Old glibc will not strip AD-bit. - Applications that want to read /etc/resolv.conf as a heuristic can look for `dnssec-enforced` option. Not the recommended way. * Is the system enforcing DNSSEC (to use an SELinux term)? - Use up a res._options bit for RES_DNSSEC_ENFORCED, meaning the admin has secured the system and DNS results follow DNSSEC rules. e.g. - res._options has RES_DNSSEC_ENFORCED set (indicates /etc/resolv.conf had the `options: dnssec-enforced`. So yes we are enforcing DNSSEC and AD-bit is not stripped, and all listed servers are trusted. - Use all the normal APIs knowing the results are secure or indeterminate. - Connected validating resolvers are trusted and drop insecure and bogus results. - res._options does not have RES_DNSSEC_ENFORCED set. So no. - Only APIs that have explicity trust information can be used. - Use getdns API. - Use new glibc APIs with DNSSEC flags per Petr's suggestions. Regardless of the mode the application can use the extended APIs with DNSSEC flags to receive perhaps all the results of a query along with trust information so it can decide which results to use and which to discard. Likewise the extended APIs with flags that request only secure results are also a valid option. You must still lock down /etc/resolv.conf to prevent someone from marking the system as secure when it is not. Higher level policy frameworks have to decide what to do about multiple connected interfaces, mixtures of trusted and untrusted networks, etc. etc. and route that information to the validating resolver whose results go to the stub resolver which is part of the running application process. How does that sound? Cheers, Carlos. diff --git a/resolv/resolv.h b/resolv/resolv.h index 53c3bba..e886610 100644 --- a/resolv/resolv.h +++ b/resolv/resolv.h @@ -221,6 +221,7 @@ struct res_sym { #define RES_USE_DNSSEC 0x00800000 /* use DNSSEC using OK bit in OPT */ #define RES_NOTLDQUERY 0x01000000 /* Do not look up unqualified name as a TLD. */ +#define RES_DNSSEC_ENFORCED 0x02000000 /* System is enforcing DNSSEC. */ #define RES_DEFAULT (RES_RECURSE|RES_DEFNAMES|RES_DNSRCH|RES_NOIP6DOTINT) ---