域名解析系统（DNS）是互联网安全的许多薄弱环节之一；可以将应用程序所访问的主机对应的 IP 地址误导到其它地方。也就是说，会连接到错误的位置，从而引发 中间人 （ man-in-the-middle ） 攻击等等。而 DNSSEC 扩展协议则通过为 DNS 信息建立一条加密的可信通道来解决这个漏洞。在正确地配置好 DNSSEC 后，应用程序将可以得到可靠的主机查询信息。通过关于尝试将 DNSSEC 更好地集成到 GNU C 库里的讨论，我们知道，确保 DNS 查询信息安全这件事并不是那么简单。

从某种意义上来说，这个问题多年以前就解决了，我们可以配置一个本地域名服务实现完整的 DNSSEC 校验 （ verification ） 并允许应用程序通过 glibc 函数来使用该服务。DNSSEC 甚至还可以用于提高其他领域的安全性，比如，它可以携带 SSH 或 TLS 密钥指纹，让应用程序可以确认其在与正确的服务器对话。不过，当我们希望确认这条自称带有 DNSSEC 校验的 DNS 结果是不是真的已通过认证的时候 - 也就是说，当我们想依赖 DNSSEC 所承诺的安全的时候，事情变得有点复杂。

/etc/resolv.conf 问题

从 glibc 的角度来看，这个问题一部分是因为 glibc 本身并没有做 DNSSEC 校验，而是引用 /etc/resolv.conf 文件，从该文件里读出的服务器来做解析以及校验，再将结果返回给应用程序。如果应用程序使用底层 res\_query() 接口，那结果中将会包含“ 已认证数据 （ authenticated data ） ”（AD）标识（如果域名服务器设定了的话）以表示 DNSSEC 校验已经成功。但是 glibc 却完全不知道提供这些结果的域名服务器的信用，所以它其实并不能告诉应用程序结果是否真的可靠。

由 glibc 的维护者 Carlos O'Donell 提出的建议是在 resolv.conf 文件里增加一个选项（dns-strip-dnssec-ad-bit）告诉 glibc 无条件移除 AD 标识。这个选项可以由各发行版设定，表示 DNSSEC 级别的 DNS 查询结果并不可靠。而一旦建立好合适的环境可以获得可靠的查询结果后，再移除这个选项。这样一来，虽然问题还没有完全解决，至少应用程序有依据来评价从 glibc 获取的 DNS 查询结果的可靠性。

一个可靠的环境配置应该是什么样？标准情况应该和这个差不太多：有一个本地域名服务器，通过 环路 （ loopback ） 接口访问，作为访问 /etc/resolv.conf 文件的唯一条目。这个域名服务器应该配置来做校验，而在校验失败后就只是简单地不返回任何结果。绝大多数情况下，应用程序就不再需要关心 AD 标识，如果结果不可靠，应用程序就根本看不到。一些发行版已经倾向于这种模型，不过情况仍然不像一些人所设想的那么简单。

其中一个问题是，这种方式将 /etc/resolv.conf 文件放到整个系统可信任度的中心。但是，在一个典型的 Linux 系统里，有无数的 DHCP 客户端、网络脚本以及其他更多的程序可以修改这个文件。就像 Paul Wouters 所指出的，在短时间内锁定这个文件是不可能的。有时候这种修改是必须的：在一个无盘系统启动的时候，在自身的域名服务器启动之前也是需要域名服务的；一个系统的整个 DNS 环境也会根据所连接的网络不同而有所改变；运行在容器里的系统也最好是配置成使用宿主机的域名服务器；等等。

所以，现在一般认为，现有系统里的 /etc/resolv.conf 文件并不可信。于是有人提出增加另一个配置文件（/etc/secure-resolv.conf 或其他什么），但这并没有从根本上解决问题。除此之外，有些参与者觉得就算有一个运行在环路接口上的域名服务器也不是真正可靠，比如 Zack Weinberg 甚至建议系统管理员可以有意禁用 DNSSEC 确认 （ validation ） 。

既然当前系统里的配置不足以信任，那可以这样推断，在情况有改善能够取得可信的结果后，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/664776/

作者：Jonathan Corbet 译者：zpl1025 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

对于自由软件来说，其最大的自由之一就是能够用一个更新或修改的版本来替换原始版本的程序。尽管如此，数千万使用那些手机里面装着所谓 Linux 的用户却很少能够在他们的手机上运行 主线内核 （ mainline kernel ） ，即使他们拥有替换内核代码的专业技能。可悲的是，我们必须承认目前仍然没有可以运行主线内核的主流手机。在由 Rob Herring 主持的2015届 内核峰会 （ Kernel Summit ） 上，与会人员共同探讨了这个问题，并进一步谈论了他们应该怎么做才能解决这个问题。

当主持人提问的时候，在座的大多数开发人员都表示他们更乐意在他们的手机上面运行主线内核，然而也有少数人持相反的看法。在 Project Ara 的支持下，Rob 在这个问题上已经研究了近一年半的时间（参见：https://lwn.net/Articles/648400/ ）。但是最新的研究成果并不理想。

Rob 表示，通常手机上运行了太多的 过期 （ out-of-tree ） 代码；主线内核只是缺少能使手机正常运行所必须的驱动。每台常规的手机都在运行着100万行到300万行的 过期 （ out-of-tree ） 代码。几乎所有的这些手机的内核版本都不超过3.10，有一些甚至更加古老。造成这种情况的原因有很多，但是有一点是很清楚的，在手机的世界里，一切都变化的太快以至于无法跟上内核社区的步伐。如果真是那样，他问到，我们还担心什么呢？

Tim Bird 指出，第一台 Android 手机 Nexus 1 从来没有运行过任何一个主线内核，并且以后也不会。它打破了开源的承诺，也使得用户不可能做到将一个新的内核放到手机中。从这一点上来说，没有任何一款手机支持这种能力。Peter Zijlstra 想知道从一台手机到另一台手机到底复制了多少能够工作的过期代码；Rob 表示，迄今为止，他已经见到了三个独立开发的热插拔 Governors。

Dirk Hohndel 提出了很少有人注意到的建议。他说，对于世界上的数以亿计的手机，大约只有他们27个人关心他们的手机是否运行着主线内核。剩下的用户仅仅只是想让他们的手机正常工作。或许那些关注手机是否在运行主线内核的开发者正在努力去解决这个令人不解的问题。

Chris Mason 说，那些手机厂商当前正面临着相同类型的问题，而这些问题也是那些 Linux 发行版过去所面临过的问题。他们疲于应付大量的无效且重复和能被复用的工作。一旦这些发行版决定将他们的工作配合主线内核而不是使用自己维护的内核，那么问题将会变得好解决的多。解决问题的关键就是去帮助手机制造商们认识到他们可以通过同样的方式获得便利，形成这种认识的关键并不是通过来自用户的压力。这样一来，问题就可以解决了。

Grant Likely 提出了对于安全问题的担忧，这种担忧来自于那些不能升级他们的手机系统的 android 设备。他说，我们需要的是一个真正专为手机设立的发行版。但是，只要手机厂商仍然掌控着手机中的应用软件，那么手机的同步更新将无法实现。我们接下来将面临一个很大的安全难题。Peter 补充说，随着 Stagefright 漏洞的出现，难题已经出现在我们面前了。

Ted Ts'o 说，运行主线内核并不是他的主要关注点。他很乐于见到这个假期中所售卖的手机能够运行3.18或者4.1的内核，而不是继续停留在3.10。他认为这是一个更可能被解决的问题。Steve Rostedt 认为，按照 Ted Ts'o 所说的那样去做并不能解决手机的安全问题，但是，Ted 认为使用一个更新一些的内核至少可以让漏洞修复变得更加容易。Grant 对此回应说，接下来的一年里，这一切都将再次发生；过渡到更新的内核也是一个渐进式的对系统的完善。Kees Cook 补充说，我们无法从修复旧版本的内核漏洞的过程中得到太多的益处，真正的问题是我们没有对 bug 的应对措施（他会在今天的另外一个对话中讲到这个话题）。

Rob 说，任何一种解决方案都需要得到当前市场上的手机供应商的支持。否则，由于厂商对安装到他们生产的手机上的操作系统的封锁，运行主线内核的策略将会陷入麻烦。Paolo Bonzini 提问说是否可以因为那些没有修复的安全漏洞而控告手机厂商，尤其当手机仍然处于保修期内。Grant 认为对于手机的 可更新能力 （ upgradeability ） 的保证必须来源于市场需求，否则是无法实现的。而促使它实现的原因可能会是一个严重的安全问题，然后用户开始对手机的可更新能力提出要求。同时，内核开发人员必须不断朝着这个方向努力。Rob 表示，除了到目前为止指出的所有优点之外，运行主线内核也能帮助开发者对安卓设备上的新特性进行测试和验证。

Josh Triplett 提问说，如果手机厂商提出对主线内核提供支持的想法，那么内核社区又将采取什么措施呢？那样将会针对手机各方面的特性要求对内核进行大量的测试和验证；Android 的兼容性测试套件中出现的失败将不得不被再次回归到内核。Rob 提议这个问题可以在明年讨论，即先将最基本的功能做好。但是，Josh 强调说，如果这个需求出现了，我们就应该能够给出一个好的答案。

Tim 认为，当前，我们和厂商之间存在很大的脱节。厂商根本不会主动报告或者贡献任何反馈给社区。他们之间完全脱节了，这样的话永远不会有进步。Josh 表示，当厂商们开始报告他们正在使用的旧内核的相关 bug 时，双方之间的接受度将变得更加友好。Arnd Bergmann 认为，我们需要的是得到一个大芯片厂商对使用主线内核的认可，并且将该厂商的硬件提升到能够支持主线内核的运行的这样一个水平，而这样将会在其他方面增加负担。但是，他补充说，实现这个目标要求存在一个跟随硬件一起分发的自由 GPU 驱动程序——然而这种程序当前并不存在。

Rob 给存在问题的领域列了一个清单，但是现在已经没有太多的时间去讨论其中的细节了。WiFi 驱动仍然是一个问题，尤其是当这个新特性被添加到 Android 设备上的时候。Johannes Berg 对新特性仍然存在问题表示赞同；Android 的开发人员甚至在这些新特性被应用到 Android 设备上之前都不会去谈论它们是否存在问题。然而，对这些特性中的大多数的技术支持最终都会落实在主线内核中。

随着会议逐渐接近尾声，Ben Herrenschmidt 再次重申：实现在 Android 手机上运行主线内核的关键还是在于让厂商认识到使用主线内核是它们获得最大利润的最好选择。从长远看，使用主线内核能节省大量的工作。Mark Brown 认为，以前，当搭载在 Android 设备上的内核版本以更稳定的方式向前推进的时候，上游工作的好处对运营商来说更加明显。以现在的情况来看，手机上的内核版本似乎停留在了3.10，那种压力是不一样的。

这次谈话以开发者决定进一步改善当前的状况而结束，但是却并没有对如何改善提出一个明确的计划。

via: https://lwn.net/Articles/662147/

作者：Jonathan Corbet 译者：kylepeng93 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出