2017年的Linux内核防护依然脆弱，2018防护是否能够加强？

Linux 内核 “社区” 对待安全的优先级并不高，虽然经历了 2000 年代的多次大规模漏洞利用事件但并没有让 Linus Torvalds 本人改变 "A bug is bug" 的哲学，由于 Linux 内核的安全问题逐渐影响到了 Android 和 IoT 设备，一次 华盛顿邮报的曝光促使了 KSPP（Linux 内核自防护项目）的成立，KSPP 是由 Linux 基金会旗下的 CII（基础架构联盟）管理，其吸纳了来自诸多大厂商（Google, RedHat, Intel, ARM 等）的工程师进行联合工作，可惜的是两年的时间过去了，KSPP 大多时候只是在重复的抄袭 PaX/Grsecurity 的各种特性以获得各自雇主那里的 KPI 和 credit，各种混乱的代码合并到了 Linux 主线影响了 PaX/Grsecurity 的正常开发，这也是 PaX/Grsecurity 关闭公开访问 test patch 的主要原因之一。

最近由 Qualys 曝光的 Stack clash 是一个古老的漏洞利用平面的工程化，这威胁到了几乎所有类 UNIX 系统（包括 GNU/Linux）的安全，当 Linux 内核 x86 的 maintainer 之一 Andy Lutomirski 问及 PaX/Grsecurity 是如何修复时 Linus 直接回复了 Grsecurity 是垃圾，有趣的是当 PaX/Grsecurity 的作者之一 Spender 曝光了一些内核最近的 silent fix 以后 Linus 居然 “邀请”PaX team/Spender 直接贡献代码到 Linux 内核代码，这是不大可能发生的，因为今天所谓的内核 “社区” 主要是由一帮大厂商的雇员组成，没有人有义务免费的贡献代码去帮助那些需要从雇主那里获得 KPI 的工程师。

        更讽刺的是， stack clash 的部分修复居然来自 PaX/Grsecurity 于 2010 年的代码，Linus 说 PaX/Grsecurity 是垃圾也等同于打 KSPP 的脸，因为 KSPP 还在继续抄袭 PaX/Grsecurity，而针对 Linux 内核的漏洞利用是否大规模被恶代使用只是曝光与否的问题。此外，虽然 Stack clash 的 * EMBARGOED" 从开始到现在已经 1 个月，但至今 CVE-2017-1000370(offset2lib bypass) 仍然未修复，RedHat 网站上所谓的 "Under Investigation" 只是继续等待 Linux 主线内核的修复，或许要让 Linux 内核安全有所改善我们需要更多的 stack clash 和 DirtyCow 持续曝光。

因为利益的关系，Linux 基金会对自由软件社区和 GPL 已经非常不友好，虽然 Greg K-Hartman 一直强调 Linux 基金会是一个非盈利组织，但一个 NGO 的 CEO 为什么有高达 49 万美金（2014 财年）的年薪，也没人知道为什么 Greg 本人会有 Google 的邮箱（拿 Linux 基金会和 Google 双薪水？），Linux 内核本来有一次改善安全的机会，可惜 Linux 基金会的市场 PR 需求搞砸了整件事。HardenedLinux 社区在这里建议所有的 GNU/Linux 用户请认真重新评估数据资产的重要性所对应的安全等级。"

匿名网友评论：

Linus 的立场其实很清楚，合并到 Linux mainstream 的代码必须逻辑拆分（便于各子系统统一维护）、可阅读理解、可审计。其中，可审计的要求有两方面：代码在版权上不存在问题；代码容易理解技术原理和设计思路。Linux 现在的内核代码贡献机制是长期以来形成的，特别是 commit log 这个环节，拆分后的 commit log 描述是技术上的需要，更是版权上的需要。了解 commit log 约定的历史的人，会很清楚为什么这么要求。不了解但感兴趣的可以看 SCO v IBM 案之后，在 Linux 内核 commit log 中引入 signoff 标签的历史(https://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-git-for 。Linus 的原始邮件没搜索到，知道的人请补充）。PaX/Grsecurity 一直以来漠视这方面的要求，不拆分 patch（提交的是大 patch），不符合代码进入 Linux mainstream 的约定规范。相关维护者不得不猜测逻辑并拆分相关代码，这又被 PaX/Grsecurity 描述为 copy/paste “抄代码”。PaX/Grsecurity 对 Linux 内核维护方式、对 Linux Foundation 充满敌意。即使在这次论战中，Linus 也一贯地表达 PaX/Grsecurity 应该拆分代码以达成直接贡献 Linux mainstream 的目标，避免其他人去猜测实现原理及拆分代码；而 PaX/Grsecurity 则纠缠于 Linux 中存在各种 bug（包括 Linus 自己引入的 security bug），消极合作甚至不合作。Spender 提到的的 vmappable stack 的 CVE，更是其不合作、看笑话的敌视态度的体现。一个特性进入 Linux mainstream，特别是核心的 vm 管理部分，是需要长时间的反复 RFC (request for comment)，反复改进过程的。不在 RFC 过程中指出问题和改进，其“我是对的，我是专家，你们这些Linux maintainer都是傻瓜”的心态可见一斑。至于 KPI 之说，更是欲加之罪。Linux 发展到今天，依赖出于兴趣的 random contributor 是不够的，sponsored developer 成为主力是不可避免的。某些代码代表厂商利益和诉求，但大部分的贡献是 vendor neutral 的。比如 Google 塞进了 binder (Android 需要)，但也贡献了 TFO (tcp fast open)、lockless listen、BBR(bottleneck bandwidth & rtt) 等相当大一批重要的代码，这些是所有使用者及那些并不贡献代码的互联网公司都受益的；又比如 livepatch 方面，SUSU/RedHat 扯皮拉筋，政治因素比较多，但项目也一直在前行。”KSPP 大多时候只是在重复的抄袭 PaX/Grsecurity 的各种特性以获得各自雇主那里的 KPI 和 credit，各种混乱的代码合并到了 Linux 主线影响了 PaX/Grsecurity 的正常开发“，这个困境并不是 Linus 及 Linux Foundation 愿意的，但 Pax/Grsecurity 显然不想正常方式解决，只想内核维护者屈服和放弃原则。