[翻译]Linux4.13中的新安全特性-外文翻译-看雪-安全社区|安全招聘|kanxue.com

[翻译]Linux4.13中的新安全特性

发表于: 2017-9-11 22:09 3360

[翻译]Linux4.13中的新安全特性

StrokMitream 活跃值

2017-9-11 22:09

3360

Linux4.13中的新安全特性

本文简要概括一下最新发布的Linux内核v4.13的一些有趣的新安全特性。

安全文档ReSTification

我们已经切换到用ReST排版内核文档，并且我也注意到，到目前为止Documentation/security/目录树并未转换过来。我借机将其中一些重新排版，并按Jon Corbet的建议划分为终端用户文档（主要是关于如何使用Linux安全模块）和开发者文档（主要是关于如何使用各种内部API）。还有一大批这样的文档亟待更新，故希望通过增加“曝光率“，以期大家更多的关注。

CONFIG_REFCOUNT_FULL

自从Peter Zijlstra在v4.11中引入refcount_t API，Elena Reshetova(以及Hans Liljestrand和Davis Windsor)已经有计划、有步骤地用refcount_t替代atomic_t引用计数器。至于v4.13，已有将近125个已被转换，未来将会有更多。然而，一些网络模块、子系统模块的维护者担忧refcount_t的性能。为了缓和这些担忧以及持续推进更换进程，我添加了一个“未审核的“refcount_t(与早期的atomic_t完全一样)作为默认选项。现在，完整审核过的CONFIG_REFCOUNT_FULL已经可用了。我们计划对于v4.14及其后续版本，内核将会开发针对特定架构、性能与atomic_t相当的refcount_t。

CONFIG_FORTIFY_SOURCE

Daniel Micay新开发的glibc的FORTIFY_SOURCE，将会在编译和运行时检查常用数组函数(例如strcpy,strcmp)和内存函数（如memcpy,memcmp）的溢出。其想法是，既然编译器知道这些函数的大多数参数的缓冲区大小，那么便可以在编译器内检查缓冲区溢出问题。进行编译时，所有变量的大小已经确定，如果检查出有缓冲区溢出风险，便可立即终止编译，从而降低了缓冲区溢出风险。如果仅有一些参数大小确定（输出变量的大小在编译时即确定，而输入变量的大小直到运行输入数据时方能确定），增加的运行时检查将进一步截住缓冲区溢出危险。添加后，发现仍有少量泄露，我和Daniel紧急修复了这一小问题。

我注意到其中有趣的一点，该保护机制只检查整个对象的大小，例如（via_builtin_object_size(…,0)）。如果结构内是字符串，当前的CONFIG_FORTIFY_SOURCE只会阻止你在外部随意复制，但是对于在结构内部的溢出，它也无能为力。接下来。我们将进一步增强其保护能力。然而，在许多情况下，内核总是有意地跨域复制数据,这意味着高等级的行为难以修正。

前置NULL栈警惕标志

Rik van Riel和Daniel Micay改变了定义在64位系统上的栈警惕标志的前导字节为0的实现。该机制明确了对字符串函数（如，strcpy）的溢出防范，这将有效阻止对NULL字节的读取、写入操作。与此同时，也将触发栈警惕标志（Stack Canary）的检查。这将使随机数熵由64bits降低到56bits，不过，权衡利弊之下，这样做还是·值得的。

IPC重构

为了部分地支持IPC结构层通过randstruct插件随机化，Manfred Spraul和我重新组织了IPC在内核中跟踪调用的实现内部层次。结果的分配变得更小、更易于处理。

Randstruct gcc插件

我把grsecurity的randstruct gcc插件移植过了。该插件允许结构层在每次构建起来后随机化，有效地防范针对敏感结构域在内核内存位置的攻击。通过将周围的事物活动起来（即随机化），使得攻击者在挂载有效攻击前将花费大量精力。

不幸的是，由于开发周期短促，目前只能通过手动模式开启该功能。V4.14将会开启自动模式，随机化所有仅含有函数指针的结构。

自从v4.10到现在的v4.13，我们对randstruct进行了大量的修订，大多数是grsecurity完成的，这些新奇的功能，既不像新添加的驱动，如whitelisted cross-struct casts,又不是在上游测试中发现的corner case on ARM。

降低ELF_ET_DYN_BASE

Stack Clash系列漏洞中最为突出的问题是：由于默认的ELF_ET_DYN_BASE（可执行程序在内存中出现可能性最低的位置）在内存已经处于较高位置，最高位置部分的PIE程序文本内存可能造成堆栈内存冲突。要解决该问题需要告诉ELF装载器如何在内存映射区加载作为共享对象的中断而不是作为PIE可执行程序（为了避免在加载过程中潜在的冲突）。最终结果是，在32位系统上，PIE默认位置可低到ET_EXEC（0x400000），完全避免了Stack Clash。在64位操作系统上，可达到较32位系统稍高的地址空间（0x100000000），将整个32位的空间开放用于32位寻址，不过，在后期发现，Address Sanitizer无法处理地址的移动。由于大多数Stack Clash只在32位平台具有可行性，解决64位系统只能等到有有效方法让Address Sanitizer可以以共享对象的方法载入自身再说了。