Merge pull request #109 from LCTT/master

更新至2015年1月24日

sources/tech/20151202 A new Mindcraft moment.md

@@ -1,3 +1,4 @@
+zpl1025
 A new Mindcraft moment?
 =======================
 

sources/tech/20151206 Supporting secure DNS in glibc.md

@@ -1,47 +0,0 @@
-zpl1025
-Supporting secure DNS in glibc
-========================
-
-Credit: Jonathan Corbet
-
-One of the many weak links in Internet security is the domain name system (DNS); it is subject to attacks that, among other things, can mislead applications regarding the IP address of a system they wish to connect to. That, in turn, can cause connections to go to the wrong place, facilitating man-in-the-middle attacks and more. The DNSSEC protocol extensions are meant to address this threat by setting up a cryptographically secure chain of trust for DNS information. When DNSSEC is set up properly, applications should be able to trust the results of domain lookups. As the discussion over an attempt to better integrate DNSSEC into the GNU C Library shows, though, ensuring that DNS lookups are safe is still not a straightforward problem.
-
-In a sense, the problem was solved years ago; one can configure a local nameserver to perform full DNSSEC verification and use that server via glibc calls in applications. DNSSEC can even be used to increase security in other areas; it can, for example, carry SSH or TLS key fingerprints, allowing applications to verify that they are talking to the right server. Things get tricky, though, when one wants to be sure that DNS results claiming to have DNSSEC verification are actually what they claim to be — when one wants the security that DNSSEC is meant to provide, in other words.
-
-The /etc/resolv.conf problem
-
-Part of the problem, from the glibc perspective, is that glibc itself does not do DNSSEC verification. Instead, it consults /etc/resolv.conf and asks the servers found therein to do the lookup and verification; the results are then returned to the application. If the application is using the low-level res_query() interface, those results may include the "authenticated data" (AD) flag (if the nameserver has set it) indicating that DNSSEC verification has been successfully performed. But glibc knows nothing about the trustworthiness of the nameserver that has provided those results, so it cannot tell the application anything about whether they should really be trusted.
-
-One of the first steps suggested by glibc maintainer Carlos O'Donell is to add an option (dns-strip-dnssec-ad-bit) to the resolv.conf file telling glibc to unconditionally remove the AD bit. This option could be set by distributions to indicate that the DNS lookup results cannot be trusted at a DNSSEC level. Once things have been set up so that the results can be trusted, that option can be removed. In the meantime, though, applications would have a way to judge the DNS lookup results they get from glibc, something that does not exist now.
-
-What would a trustworthy setup look like? The standard picture looks something like this: there is a local nameserver, accessed via the loopback interface, as the only entry in /etc/resolv.conf. That nameserver would be configured to do verification and, in the case that verification fails, simply return no results at all. There would, in almost all cases, be no need to worry about whether applications see the AD bit or not; if the results are not trustworthy, applications will simply not see them at all. A number of distributions are moving toward this model, but the situation is still not as simple as some might think.
-
-One problem is that this scheme makes /etc/resolv.conf into a central point of trust for the system. But, in a typical Linux system, there are no end of DHCP clients, networking scripts, and more that will make changes to that file. As Paul Wouters pointed out, locking down this file in the short term is not really an option. Sometimes those changes are necessary: when a diskless system is booting, it may need name-resolution service before it is at a point where it can start up its own nameserver. A system's entire DNS environment may change depending on which network it is attached to. Systems in containers may be best configured to talk to a nameserver on the host. And so on.
-
-So there seems to be a general belief that /etc/resolv.conf cannot really be trusted on current systems. Ideas to add secondary configuration files (/etc/secure-resolv.conf or whatever) have been floated, but they don't much change the basic nature of the situation. Beyond that, some participants felt that even a local nameserver running on the loopback interface is not really trustworthy; Zack Weinberg suggested that administrators might intentionally short out DNSSEC validation, for example.
-
-Since the configuration cannot be trusted on current systems, the reasoning goes, glibc needs to have a way to indicate to applications when the situation has improved and things can be trusted. That could include the AD-stripping option described above (or, conversely, an explicit "this nameserver is trusted" option); that, of course, would require that the system be locked down to a level where surprising changes to /etc/resolv.conf no longer happen. A variant, as suggested by Petr Spacek, is to have a way for an application to ask glibc whether it is talking to a local nameserver or not.
-
-Do it in glibc?
-
-An alternative would be to dispense with the nameserver and have glibc do DNSSEC validation itself. There is, however, resistance to putting a big pile of cryptographic code into glibc itself. That would increase the size of the library and, it is felt, increase the attack surface of any application using it. A variant of this idea, suggested by Zack, would be to put the validation code into the name-service caching daemon (nscd) instead. Since nscd is part of glibc, it is under the control of the glibc developers and there could be a certain amount of confidence that DNSSEC validation is being performed properly. The location of the nscd socket is well known, so the /etc/resolv.confissues don't come into play. Carlos worried, though, that this approach might deter adoption by users who do not want the caching features of nscd; in his mind, that seems to rule out the nscd option.
-
-So, in the short term, at least, it seems unlikely that glibc will take on the full task of performing validated DNSSEC lookups. That means that, if security-conscious applications are going to use glibc for their name lookups, the library will have to provide an indication of how trustworthy the results received from a separate nameserver are. And that will almost certainly require explicit action on the part of the distributor and/or system administrator. As Simo Sorce put it:
-
-A situation in which glibc does not use an explicit configuration option to signal applications that it is using a trusted resolver is not useful ... no scratch that, it is actively harmful, because applications developers will quickly realize they cannot trust any information coming from glibc and will simply not use it for DNSSEC related information.
-
-Configuring a system to properly use DNSSEC involves change to many of the components of that system — it is a distribution-wide problem that will take time to solve fully. The role that glibc plays in this transition is likely to be relatively small, but it is an important one: glibc is probably the only place where applications can receive some assurance that their DNS results are trustworthy without implementing their own resolver code. Running multiple DNSSEC implementations on a system seems like an unlikely path to greater security, so it would be good to get this right.
-
-The glibc project has not yet chosen a path by which it intends to get things right, though some sort of annotation in /etc/resolv.conf looks like a likely outcome. Any such change would then have to get into a release; given the conservative nature of glibc development, it may already be late for the 2.23 release, which is likely to happen in February. So higher DNSSEC awareness in glibc may not happen right away, but there is at least some movement in that direction.
-
---------------------------- 
-
-via: https://lwn.net/Articles/663474/ 
-
-作者：Jonathan Corbet 
-
-译者：[译者ID](https://github.com/译者ID) 
-
-校对：[校对者ID](https://github.com/校对者ID) 
-
-本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出

translated/tech/20151206 Supporting secure DNS in glibc.md

@@ -0,0 +1,46 @@
+通过修改 glibc 支持 DNS 加密
+========================
+
+感谢：Jonathan Corbet
+
+域名解析系统（DNS）是因特网安全许多薄弱环节之一；可以误导应用程序所访问的主机相应的 IP 地址。也就是说，会连接到错误的位置，可以引发中间人攻击以及更多攻击。而 DNSSEC 扩展协议是通过为 DNS 信息建立一条加密的可信通道来解决这个漏洞。在正确地配置好 DNSSEC 后，应用程序将可以得到可靠的主机查询信息。通过关于尝试将 DNSSEC 更好地集成到 GNU C 库里的讨论，确保 DNS 查询信息安全并不是那么简单。
+
+某种意义上来说，这个问题多年以前就解决了，我们可以配置一个本地域名服务实现完整的 DNSSEC 认证并允许应用程序通过 glibc 函数来使用该服务。DNSSEC 甚至还可以用于提高其他领域的安全性，比如，它可以携带 SSH 或 TLS 密钥指纹，让应用程序可以确认其在与正确的服务器通话。不过，当我们希望确认这条自称带有 DNSSEC 认证的 DNS 结果是不是真的已通过认证的时候 - 也就是说，当我们想依赖 DNSSEC 所承诺的安全的时候，事情变得有点复杂。
+
+/etc/resolv.conf 问题
+
+从 glibc 的角度来看，这个问题一部分是因为 glibc 本身并没有做 DNSSEC 认证。而是引用 /etc/resolv.conf 文件，从该文件里读出的服务器来做解析以及认证，再将结果返回给应用程序。如果应用程序使用底层 res_query() 接口，那结果中将会包含“已认证数据”（AD）标识（如果域名服务器设定了的话）以表示 DNSSEC 认证已经成功。但是 glibc 却完全不知道提供这些结果的域名服务器的信用，所以它其实并不能告诉应用程序结果是否真的可靠。
+
+由 glibc 的维护者 Carlos O'Donell 提出的建议是在 resolv.conf 文件里增加一个选项（dns-strip-dnssec-ad-bit）告诉 glibc 无条件移除 AD 标识。这个选项可以由各发行版设定，表示 DNSSEC 级别的 DNS 查询结果并不可靠。而一旦建立好合适的环境可以获得可靠的查询结果后，再移除这个选项。这样一来，虽然问题还没有完全解决，至少应用程序有依据来评价从 glibc 获取的 DNS 查询结果的可靠性。
+
+一个可靠的环境配置应该是什么样？标准情况应该和这个差不太多：有一个本地域名服务器，通过环路接口访问，作为访问 /etc/resolv.conf 文件的唯一入口。这个域名服务器应该配置来做认证，而在认证失败后就只是简单地不返回任何结果。绝大多数情况下，应用程序就不再需要关心 AD 标识，如果结果不可靠，应用程序就根本看不到。一些发行版已经偏向这种模型，不过情况仍然不像一些人所设想的没那么简单。
+
+其中一个问题是，这种方式将 /etc/resolv.conf 文件放到整个系统可信任度的中心。但是，在一个典型的 Linux 系统里，有无数的 DHCP 客户端、网络脚本以及其他更多，可以修改这个文件。就像 Paul Wouters 所指出的，在短时间内锁定这个文件是不可能的。有时候这种改变是必须的：在一个无盘系统启动的时候，在自身的域名服务器启动之前也是需要域名服务的；一个系统的整个 DNS 环境也会根据所连接的网络不同而有所改变；运行在容器里的系统也最好是配制成使用宿主机的域名服务器；等等。
+
+所以，现在一般认为，现有系统里的 /etc/resolv.conf 文件并不可信。于是有人提出增加另一个配置文件（/etc/secure-resolv.conf 或其他什么），但这并没有从根本上解决问题。除此之外，有些参与人员觉得就算有一个运行在环路接口上的域名服务器也不是真正可靠，比如 Zack Weinberg 甚至建议系统管理员可以有意禁用 DNSSEC 认证。
+
+既然当前系统里的配置不足以信任，那可以这样推断，在情况有改善能够取得可信的结果后，glibc 需要有一种方式来通知应用程序。可以是上面讨论的屏蔽 AD 标识的方式（或者与之相反，增加一个显示的“此域名服务器可以信任”选项）；当然，这都需要一定程度上锁定系统以免 /etc/resolv.conf 受到任何不可预计的修改。按 Petr Spacek 的建议，还有一种引申方式，就是提供一种途径允许应用程序查询 glibc 当前通讯的是不是本地域名服务器。
+
+在 glibc 里来处理？
+
+另一种方式是去掉域名服务器，而是让 glibc 本身来做 DNSSEC 认证。不过，把这么大一坨加密相关代码放进 glibc 也是有很大阻力。这样将增加库本身的大小，从而感觉会增加使用它的应用程序的受攻击面积。这个方向再引申一下，由 Zack 提出的建议，可以把认证相关代码放到域名服务缓冲守护进程（nscd）里。因为 nscd 也是 glibc 的一部分，由 glibc 开发人员维护，因此在一定程度上可以相信能正确执行 DNSSEC 认证。而且 nscd 的通讯 socket 所在位置也是公开的，所以可以不考虑 /etc/resolv.conf 问题。不过，Carlos 担心这种方式不能让那些不想使用 nscd 缓存功能的用户所接受；在他看来，基本可以排除 nscd 的方式。
+
+所以，至少近期内，glibc 不太可能全部执行带 DNSSEC 认证的整个查询过程。这意味着，如果一个有安全考虑的应用要使用 glibc 库来查询域名，库将需要提供一个标识来评价从独立域名服务器返回的结果有多大程度的可靠性。这几乎肯定需要发行商或系统管理员做出一些明确的改动。就像 Simo Sorce 说的那样：
+
+如果 glibc 不使用明确的配置选项来通知应用程序它所用的域名解析是可信的，不会有什么用。。。不改一下还有很大弊端，因为应用程序开发者将马上认识到他们不能信任从 glibc 获取的任何信息，从而在处理 DNSSEC 相关信息时就简单地不用它。
+
+要配置一个系统能正常使用 DNSSEC 需要改动该系统的很多组件 - 这是一个发行版范围的问题，需要时间来完全解决。在这个转变过程中 glibc 所扮演的角色很可能会比较小，但是很重要的一部分：如果应用程序不实现一套自己的域名解析代码，glibc 很可能是保证 DNS 结果可信的唯一方式。在一个系统中运行多个 DNSSEC 实现方式看起来不像是一种安全的方式，所以最好还是把事情做对了。
+
+glibc 项目目前并没有确定用哪种方式来做这个事情，虽然从 /etc/resolv.conf 文件里的某些标记看上去快好了。这种改动应该需要发布新版本；考虑到 glibc 开发的保守天性，很可能来不及加入预计二月份发布的 2.23 版本了。所以 glibc 中暂时还不会有更高安全性的 DNSSEC ，不过在这个方向上也有一些进展了。
+
+--------------------------- 
+
+via: https://lwn.net/Articles/663474/ 
+
+作者：Jonathan Corbet 
+
+译者：[zpl1025](https://github.com/zpl1025) 
+
+校对：[校对者ID](https://github.com/校对者ID) 
+
+本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出