大家好，我是极客范的本期栏目编辑小友，现在为大家讲解2017年的Linux内核防护依然脆弱，2018防护是否能够加强？问题。
2017年的Linux内核防护依然脆弱，2018防护是否能够加强？问题。Linux内核“社区”并没有给予安全性高优先级。虽然它在21世纪经历了许多大规模的开发，但并没有让Linus Torvalds改变他的“bug就是bug”的哲学。由于Linux内核的安全问题逐渐影响到安卓和物联网设备，《华盛顿邮报》的曝光促使成立了KSPP(Linux内核自我保护项目)，由Linux基金会下的CII(基础设施联盟)管理。它吸收了许多主要制造商(谷歌、红帽、英特尔、ARM等)的工程师。)一起工作。可惜，两年过去了。大多数时候，KSPP只是重复复制PaX/Grsecurity的各种功能，以获得雇主的KPI和信用。各种混沌代码融合到Linux主线中，影响了PaX/Grsecurity的正常发展，这也是PaX/Grsecurity关闭公众访问测试补丁的主要原因之一。
Qualys最近曝光的Stack clash是一个古老的剥削飞机的工程，它威胁到几乎所有类似UNIX的系统(包括GNU/Linux)的安全。当Linux内核x86的维护者之一Andy Lutomirski问及如何修复PaX/Grsecurity时，Linus直接回答Grsecurity是垃圾。有趣的是，在PaX/Grsecurity的作者之一斯彭德曝光了最近一些关于内核的静默修复后，Linus实际上“邀请”了PaX团队/斯彭德直接将代码贡献给Linux内核代码，这是不太可能发生的，因为如今所谓的内核“社区”主要由一群来自大型制造商的员工组成，没有人有义务免费贡献代码来帮助需要雇主KPI的工程师。
具有讽刺意味的是，堆栈冲突的部分修复实际上来自2010年PaX/Grsecurity的代码。Linus说PaX/Grsecurity是垃圾，相当于打了KSPP的脸，因为KSPP继续复制PaX/Grsecurity，Linux内核的漏洞是否被邪恶的几代人大规模利用，只是曝光的问题。此外，虽然距离Stack clash的* EMBARGOED开始已经一个月了，但CVE-2017-1000370(Offset 2 libbypass)还没有修复，红帽网站上所谓的“正在调查”只是继续等待Linux主线内核的修复。也许为了提高Linux内核的安全性，我们需要更多的堆栈冲突和DirtyCow暴露。
因为利益关系，Linux基金会一直对自由软件社区和GPL非常不友好。虽然Greg K-Hartman一直强调Linux基金会是非营利组织，但是为什么一个NGO的CEO年薪高达49万美元(2014财年)，而且没有人知道Greg本人为什么会有谷歌的邮箱？)，Linux内核本来有机会提升安全性，可惜Linux Foundation的市场PR需求把整个事情搞砸了。HardenedLinux社区在此建议所有GNU/Linux用户应仔细重新评估与数据资产重要性相对应的安全级别。'
匿名评论：
Linus的立场其实很明确，合并到Linux主流中的代码一定要逻辑拆分(方便各个子系统的统一维护)、可读易懂、可审计。其中对可审核性有两个要求：代码的版权没有问题；代码很容易理解技术原理和设计思想。Linux内核代码贡献机制已经形成很久了，尤其是在提交日志阶段。拆分提交日志描述不仅是技术需求，也是版权需求。了解提交日志协议历史的人会清楚地知道为什么需要它们。大家不知道但感兴趣的是SCO诉IBM案(https://stackoverflow.com/Questions/1962094/git-for-is-sign-off-feature-in-git-for)后在Linux内核提交日志中引入sign-off标签的历史。Linus的原始邮件没有被搜索到，如果你知道的话，请添加。PaX/Grsecurity总是忽略这个要求，不拆分补丁(大补丁提交)，不符合约定的代码进入Linux主流的规范。维护人员必须猜测逻辑并拆分相关代码，这被PaX/Grsecurity描述为通过复制/粘贴来“复制代码”。PaX/Grsecurity敌视Linux内核维护和Linux基金会。即使在这场争论中，Linus也始终如一地表示PaX/Grsecurity应该拆分代码，以达到直接为Linux主流做贡献的目的，从而避免其他人猜测实现原理而拆分代码。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 显然不想正常方式解决，只想内核维护者屈服和放弃原则。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 显然不想正常方式解决，只想内核维护者屈服和放弃原则。
.dfma { position: relative; width: 1000px; margin: 0 auto; } .dfma a::after { position: absolute; left: 0; bottom: 0; width: 30px; line-height: 1.4; text-align: center; background-color: rgba(0, 0, 0, .5); color: #fff; font-size: 12px; content:"广告"; } .dfma img { display: block; }