Linux 内核社区是数字军火商、斯拉夫兵工厂甚至 NSA 的最爱

声明：为了更好地向读者输出更优质的内容，InfoQ 将精选来自国内外的优秀文章，经过整理审校后，发布到网站。本文原文链接。本文已由 h4rdenedzer0 团队授权 InfoQ 中文站转载。欢迎转发，但请保留原作者信息！

编者按： Grsecurity/PaX 的应用十分广泛，特别是具有高安全性的环境。Gnu/Linux 发行版里 Gentoo 提供 PaX 作为加固选项，最近半年 Debian 社区发起的对抗大规模监控的加固项目 Mempo 在内核中也使用了 Grsecurity/PaX。因此说普通的 GNU/Linux 安全是相对于 Windows 而言。不得不说，在这个一天云计算、一天雾计算、今天框计算、明天网格计算的年代，作为一个 10 多年前的设计和实现，PaX 的思路的确令人震撼。

译者 Shawn the R0ck： Grsecurity/PaX 是在 OS 安全上的一个开创性的贡献，没有 PaX/Grsecurity 的 GNU/Linux 的安全性只能防御脚本小子，过去的 14 年里 Pax/Grsecurity 为 Linux 内核做出了巨大出贡献的贡献，但到今天 Linux 内核社区都不愿意承认，这可能的确是受商业厂商控制了主流媒体的后果，在后棱镜时代，这种现象有极端的阴谋论甚至认为 NSA 也是推手，当然这也并非完全没有道理，毕竟 SELinux 项目早已成为 Five-Eyes 国家的标配。

我尝试翻译这篇 5 年前的访谈是为了让更多的人了解到历史，因为反观今天的 Linux 内核社区对于安全的态度相比 5 年前可能是更糟糕， offset2lib 的远程利用方式轻松绕过了 GNU/Linux 厂商们宣称的完美防御，相信就算是智商只有 85 的人也能明白“抗爆破”机制只能抗不到 1 秒的时间是在扯淡 ;-)。即使 offset2lib 所带来的风险巨大，Linux 内核社区的态度也是极度傲慢，他们也不认为这个 PaX/Grsecurity 在 2001 年就已经加固的攻击平面而他们在 2015 年还存在有什么问题，而 BadiRET 漏洞里我们更能清晰的看到 SMEP 虽然被绕过，但 SMAP 依然有效，而这两个 Intel CPU 的特性也是源于 2007 年 PaX/Grsecurity 的其中一个特性 UDEREF 的启发。自从有了 OS 的攻防历史，就有了 PaX/Grsecurity，如果 Linux 内核社区继续傲慢自大，最终的受害者是企业用户和个人用户。

在 Anarchist 看来，这样的 Linux 内核社区正是数字军火商，斯拉夫兵工厂甚至 NSA 所喜欢的。

Slo-Tech：向我们的读者介绍一下你自己（工作，教育背景以及兴趣），也请你解释一下你的真名是 Spender 还是 Spengler;-) 请问 Brad 是否是任何黑帽组织的成员？

Brad Spengler:Brad Spengler(不是 Brad Spender)，虽然相似的名字并非偶然，我改了改姓氏作为别名。我毕业于 Bucknell 大学，获得了计算机与工程（混杂了计算机科学和电子硬件的课程）学士学位和一个应用数学的学士学位。数学 / 物理学 / 经济学 / 哲学都是我最有兴趣的课程。我在学习操作系统课程之前就已经有 4 年的学习 Linux 内核和编程的经历，所以计算机科学课程并不是那么的有趣。我从来没有参加过任何黑帽组织。自从高中开始我总是对创造有趣的事物有兴趣。…………………(未翻译）

Slo-Tech：你能用简单描述一下什么是 PaX 和 GRSecurity 以及有多少人参与这些项目吗？

Brad Spengler： PaX 是一头戏剧性的改变了整个安全的形态的野兽，而且对未来安全的影响甚至会更多。PaX 专注于一次性的解决一堆各种类型的漏洞利用，有一些工作还没有完成，但希望能有所改变，也希望 8 年后（Shawn：现在已经是 5 年后了，愚蠢的大众还是宁愿相信商业厂商和 NSA;-)）所有人都能明白 PaX 的前瞻性。PaX 完全专注于内存的漏洞利用， Grsecurity 则增加了主机层的防御和基于现有的 PaX 特性进行了一系列的改进，包括抗爆破，ASLR 的抗信息泄漏，不允许文件系统级别的任意代码执行等。Grsecurity 包括了很多简单的自动化特性，比如 RBAC 系统可以通过学习模式（你可以选择基于进程 / 用户或者整个系统）来自动化创建规则，这些规则都是人类可读的纯文本格式（Shawn：SELinux 是使用难以审计的二进制的格式），报错信息有助于根据攻击类型来制定相应的规则。

PaX 项目的参与人数是未知的！因此 PaX Team 至少有一个人:)，对于 Grsecurity 这边就我一个人。偶尔我也收到一些 Patch 提交（比如来自 Zbyniu Krzystolik），赞助者和朋友有时也会告诉我他们想要加入一些新功能。

Slo-Tech：只有一些人真正了解 PaX Team 开发了一些安全机制（比如 ASLR）后来被用于 Linux 内核里，至少目前来看主要的 Linux 内核社区开发者和参与者并不打算承认 PaX 所带来的贡献，你认为这些机制对于 Linux 安全贡献最大的是什么。

Brad Spengler：好吧，对我而言很搞笑的是聪明的 Ingo Molnar 多年前对于 paxtest 测试（包括检查不同区域的地址空间是否有能力执行任意代码）非常不爽，因为第 2 组测试中 mprotect 用于标记一些内存为可写和可执行。Ingo 称这个测试是“破坏”–mprotect 检测多少有些不公平（因为 exec-shield 完全失效了）。往前看几年你会发现 SELinux 基本上把 PaX 的 MPROTECT 加入了它的规则语言。在 Windows 的世界里你能找到所有人都在尝试日等价于 Linux 上的 mprotect，glibc 曾经有一个make_stack_executable()函数也是 ret2libc 攻击的对象，Windows 上也有类似的函数。PaX team 早在很多年前就认识到攻击者会找最薄弱的环节下手，而这正是今天正在发生的事情。

我不能说哪一个特性是对 Linux 安全贡献最大，因为这些特性都是叠加式的让 Linux 内核更安全。同样，我认为下一个最具革命性的贡献将同样来自 PaX team。

Slo-Tech：看起来 Brad 和 Linux 内核开发者的“口水战”还在继续。什么是主要原因导致了这种不愉快的情况？你不认为其实 GNU/Linux 的终端用户才是遭受损失的吗？

Brad Spengler：我从来都没有发过一封邮件到 LKML（Linux 内核邮件列表），所以我并没有参与任何“口水战”。PaX Team 曾经发过邮件到 LKML（比如让 Linux 内核开发者承认他们的不愿意让外界关注的不披露漏洞的官方政策和安全漏洞信息模糊化以及 Linus 为此多次赢得 pwnie 奖项的”a bug is bug”的安全哲学）。8 个公开的空指针引用的漏洞利用才被作为提权威胁来处理，在第一个公开漏洞利用后几个月，mmap_min_addr 被引入，但并不懂安全的 Linux 开发者开发的这个安全机制导致了至少 6 个不同的绕过。Linux 内核的 ASLR 有大量的弱点。SSP 被攻破了多次最终导致他们强行限制其工作范围。所有这些破事都来自于一个商业源头：Red Hat——对于公司重要的是为了赚钱你要说你有 X 特性（比如反病毒厂商会宣称：“我们将会保护你不受病毒的侵害。”），至于这个特性是否有用并不是公司关心的（但有些人会去验证厂商的宣传—安全研究人员或者黑帽）。

Slo-Tech：谁是你尊重的 Linux 内核开发者？或者说，你不觉得在安全问题上 Linux 需要重新组织一下关于处理安全事件和安全开发的流程（很多回归测试代码）。比如微软的 SDL……你觉得 SDL 怎么样？

Brad Spengler：基于有很多公司和个人用户使用微软的产品，我很尊重微软对安全的态度。Windows 在大量的二进制软件的生态系统的基础上，去实现安全功能的同时还要保证应用程序的兼容性。这些工程的真实难度很容易被误认为是简单的事情。

Linux 确实需要一些集中的领导者或者组织来处理安全。Linux 开发者就算知道他们在修复安全漏洞，但他们也不会通知任何人（包括厂商）。选择性的通知厂商特定的安全问题，而不通知小的厂商和 GNU/Linux 发行版社区。Upstream 基本上让厂商难受，每个厂商都必须去做重复的劳动，因为没有标准化流程。Linux 内核社区官方的”a bug is just a bug”政策是在伤害所有的 GNU/Linux 用户。一些很优秀的加固补丁很少被内核社区接受，因为他们过度看中安全机制造成的性能影响。

Slo-Tech：你觉得 Linux Torvalds 能胜任 Linux 的安全工作吗？我的意思是，他是一个优秀的开发者，但不是一个安全研究人员。那其他的著名 Linux 内核开发者呢？他们有相关的技能吗？

Brad Spengler：我不认为他能，他没有安全思维，也无法理解安全。我不确定为什么很多人都感觉在安全问题上 Linus 是否参与很重要。一些开发者“理解”安全，但通常他们只修复 bug。Upstream 通常不关心系统加固方面的内容。

Slo-Tech：Dave Aitel 写了一封名为“需要中心平台让多厂商合作来改善 Linux 内核安全问题”的邮件到他的邮件列表。你同意他的观点吗？这是正确的一步吗？你愿意为这样的中心平台工作吗？

Brad Spengler：这点上 Dave 是对的，但我并没看到这种事情在发生。最重要的是 Linus 对安全的态度必须改变才行。只要一天他还是 upstream 内核的看门人，不论他的观点对还是错都会直接影响 Linux 的安全。同时，PaX Team 和我只能继续做我们一直在做的事情，改善 Linux 的安全只有一条路：单干。

Slo-Tech：内核维护者悄然无声的修复一些内核 bug 是真的吗？**“悄然无声的修复”**是否意味着不正确的 BUG 分类和低估安全风险或者其他什么的？

Brad Spengler：是的，他们已经承认这么干过。如果你回去读读 LWN 上我的文章有一堆这样的例子。厂商在漏洞分类的问题上也非常糟糕——所有都是 DoS。我认为这个事情现在有所改善是因为他们被曝光和受到了公众的批评。部分的问题原因是没有统一的 bug 管理造成了对于同一个 bug 有不同的解释。通常不同的厂商的 bug 分析也不一样，而现在有一些厂商发的安全公告并不是安全漏洞（比如 NOMMU 是用于嵌入式系统，由于用户空间和内核空间没有隔离所以根本没有安全的设计，但至少有 2 个 CVE 是有关这种系统的 BUG）。这些事情可能会促使商业公司更愿意招聘软件开发人员而不是安全人员来完成安全有关的工作。在每天都会报无数漏洞的年代，集中处理平台和管理流程是能减轻很多工作量的。

Slo-Tech：这是个恶心的问题，所以你不愿意的话你可以不回答。你愿意为微软（像 Crispin Cowan）或者 Red Hat 工作吗？

Brad Spengler：在我大学的最后一年微软曾经邀请我去面试，但我拒绝了，因为 HR 在弄丢了我的简历 1 年后他们才想起我，而我那时已经失去去那里工作的兴趣。为 Red Hat 工作？我确定你知道答案的 ;)

Slo-Tech：众所周知你使用 Windows Vista 作为你的主要操作系统。这对于一个 Linux 内核安全研究者很奇怪。你为什么会这样选择呢？你尝试去找过 Windows 的 bug 吗？

Brad Spengler：事实上我使用的是 Windows 7–Cheddar Bay 的视频里应该是 RC 版。因为 Linux 对我而言只是用来测试和改进 Grsecurity 的。在高中和大学的时候，我曾经使用 GNU/Linux 作为我的主要桌面系统，但现在 GNU/Linux 都是在虚拟机里。以前的 Linux 的内核和用户态都简单很多。你知道那些众所周知的配置文件，如果你修改他们，一些“智能”的进程会背着你把配置改回去，你不会因为想要不同的默认配置而一定要修改 SELinux 规则。那更多的是感受到 GNU/Linux 的自由（Shawn：个人认为 Brad 说的问题应该是针对 RedHat/CentOS/Fedora 的，至少目前来看 Debian 和 Gentoo 是享有高度的自由），而自由的缺失我认为是因为商业化造成的。而游戏是我用 Windows 的主要原因。如果 Pidgin 通知我有一个新版本更新，我只是下载一个去执行，而不需要强制的更新另外 100+ 个包，那样会增加系统的风险的。

Slo-Tech：为什么你会公布漏洞利用而不是把它们卖给像 iDefense、ZDI、Immunity 这样的公司……类似像本地 root 提权漏洞像 cheddarbay、ingom0wnar、wundebar 的市场价值是什么？

Brad Spengler：我不确定他们是否关心 Linux 的本地提权漏洞——首先，这些漏洞已经在某些版本的 Linux 内核开发分支上被修复了。其次这些漏洞利用太容易编写了。所以这些漏洞利用是用于提醒大家安全的重要性的（以前的一堆讨论无法改善 Linux 内核社区的看法，但那 8 个漏洞利用做到了）。第 1 个成果是帮助到了人们去理解风险的等级（有一些人联系我说那些漏洞利用帮助他们说服了他们的老板更关注安全），因为 Linux 内核公开的漏洞利用并不是那么多，不是因为漏洞不存在，而是因为黑帽们都用于自己的目的了。第二个成果是让所有主要的的 GNU/Linux 厂商和发行版都把空指针引用的攻击平面给默认防御住了，SELinux 的漏洞也修复了，厂商更注重关于 mmap_min_addr 的问题。用户也注意到了这个特性和开启它的重要性（Shawn:mmap_min_addr 成为今天的标准安全基线），很多人也都升级了 Linux 内核。这些都是好事。我想整件事情唯一的“创新”应该是 Enlightenment 框架了（下一个问题跟这个有关）。

Slo-Tech：最近你发布的针对 Linux 内核漏洞利用的框架叫 Englightenment。你是否有计划继续改进这个框架并且希望它成为像 Metasploit 一样？

Brad Spengler：我一直在改进这个框架因为她让我以攻击者的方式来思考，这会帮助我有多种思路去考虑针对特定攻击的防御机制（我最近在 Grsecurity 里实现的加固就是来源于此）。我也想让她变得尽量通用：她已经支持 x86 和 x86_64 平台的所有 2.4 和 2.6 内核上关闭所有 LSM 模块。我最近也增加了 Xen 特性的支持，这个特性会更恰当的让 hyppercall 去修改内核代码。我也在考虑关于 namespace/container(Shawn：就是 lxc，以及后来 Docker 用的底层模块），这些都在 TODO list 上。 Enlightenment 会仅仅针对 Linux 内核漏洞利用。

Slo-Tech：大多数人都不把本地漏洞利用提权当成真正的威胁。我知道 SuSE 的 Sebastian Krahmer 写过相关的观点而我也同意他的观点，但事实上现在已经没有任何公开的远程漏洞利用了（Sgrakkyu 是最后一名勇士），远程漏洞利用标准 Linux 内核真的已经是不可能还是在不远的将来会有所改变？

Brad Spengler：远程内核漏洞利用非常困难，特别是针对运行 PaX 的内核和定制过的内核。只要读读 sgrakkyu/twiz 在 Phrack 上的论文《Attacking the core:Kernel exploitation notes》（Shawn：发表于 Phrack Issue 64，2007 年）就知道所涉及的复杂性。他们都是热衷于挑战高难度的人，而其他大部分人会选择更简单的方式，比如从 Web 进入然后使用本地内核提权漏洞的方式。如果系统运行了最新的 PaX，漏洞利用会变得极度困难，而不是更简单。我仍然能看到现有的威胁会在可预见的未来存在下去，因为 GNU/Linux 发行版都把时间浪费在了不太可能出现严重 bug 的 SUID 程序上，而新的内核提权漏洞几乎每个礼拜都在曝光。还有就是 Web 开发人员（那些编写的第三方代码运行在公共的服务器上，让远程用户能进入“非信任的本地用户”）并没有变得更聪明。

Slo-Tech：GNU/Linux 能依然被认为是安全的操作系统吗？你觉得政府或者其他对安全性要求高的基础架构应该使用 GNU/Linux 吗？

Brad Spengler：我希望在高安全要求的环境中有其他的系统可以使用 (Shawn: 经过加固的 GNU/Linux 或者 Quebes OS/Mirage OS?)。作为建议，一个安全的操作系统可能会犯下非常不安全愚蠢的错误，而一个不安全的操作系统可以变得安全如果不跑任何业务的话。

Slo-Tech：你有任何私人的 0-day 漏洞利用在你的硬盘上吗 ;)

Brad Spengler：有的， ext4_own.tgz ，它小于 1000bytes。

感谢 Brad Spengler 的访谈。

阅读原文：《 Brad Spengler (PaX Team/grsecurity) interview 》

更多参考
1、PaX 的技术考古之旅：英文版、中文版

2、针对 64 位 Linux 内核的 ASLR 防护的绕过 1 、 2

感谢魏星对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群）。