泰晓资讯·3月 / 第一期 / 2020

“泰晓资讯”，广泛报道 “Linux/开源” 业界资讯。欢迎广大读者投递相关资讯来源和素材，本站将进一步收集整理后发布给大家。

颗粒度更细的内核地址空间分布随机化

The idea behind kernel address-space layout randomization (KASLR) is to make it harder for attackers to find code and data of interest to use in their attacks by loading the kernel at a random location. But a single random offset is used for the placement of the kernel text, which presents a weakness: if the offset can be determined for anything within the kernel, the addresses of other parts of the kernel are readily calculable. A new “finer-grained” KASLR patch set seeks to remedy that weakness for the text section of the kernel by randomly reordering the functions within the kernel code at boot time.

内核地址空间分布随机化（Kernel Address-Space Layout Randomization，简称 KASLR）技术会把 kernel 加载到一个随机的地址，从而使得攻击者更加难于找到他们感兴趣的目标代码或数据。不过它仅仅是给 kernel 的代码段施加了一个随机偏移量，这么做其实还是有漏洞的，譬如如果攻击者获取到了 kernel 里部分数据的地址，那么他就可以推算出 kernel 里所有其他数据的位置。最近 Kristen Carlson Accardi 提出了一个颗粒度更细的 KASLR 补丁，希望能通过在 kernel 启动过程中对各个函数进行重新排序，来弥补目前方案对 kernel 代码段保护上的缺陷。经过测试发现内核加入该补丁后只会增加 1 秒钟的启动耗时。目前对于这个补丁的反馈都还是很正面的。没有人提出对于这个目标的反对意见。Accardi 也说这个主意本身并不新奇，此前已经有许多相关的研究。比如 OpenBSD 就使用了一个类似的机制来在启动时对kernel 进行随机化。当然，后续还是有很多工作要做，不过大概率来说今年应该会看到这个功能合入 mainline 的。更多细节描述可以参阅原文 “Finer-grained kernel address-space layout randomization”。

关键词: Linux，KASLR

利用 memfd 机制对内存映射添加更安全的保护

Back in November 2019, Mike Rapoport made the case that there is too much address-space sharing in Linux systems. This sharing can be convenient and good for performance, but in an era of advanced attacks and hardware vulnerabilities it also facilitates security problems. At that time, he proposed a number of possible changes in general terms; he has now come back with a patch implementing a couple of address-space isolation options for the memfd mechanism. This work demonstrates the sort of features we may be seeing, but some of the hard work has been left for the future.

2019 年 11 月时，Mike Rapoport 在欧洲开源峰会上曾经 指出，在 Linux 系统中有太多地方存在地址空间共享（address-space sharing）的情况。这种共享很便捷，对性能有好处，但是由于现在出现了许多复杂的攻击方式，特别是硬件上的安全风险（譬如 Meltdown 和 Spectre 这两个硬件 bug），所以地址空间共享很容易造成安全问题。当时他提出了一些改动的建议，最近他以实际行动给出了对应的补丁修改，其主要思路是希望利用 memfd 机制对一些地址空间进行隔离。

memfd 自系统设计之初并不是用于 address-space isolation 的，它的目的实际上是为了实现一种进程间通信的机制。不过，它确实也提供了一种能力可以把一个内存区域关联到一个文件描述符上同时通过文件描述符对这个内存对象设置一些特殊的属性。比如可以把一个 memfd 改为 “sealed” 状态，这样 IPC 的接收方就能知道这块内存区域中的内容是不会被改变的。Rapoport 认为这个基于这个特性会非常有助于实现 “secret memory” 功能。

这个补丁提出来的目的之一就是请大家提出宝贵意见，不过目前还没有太多的反馈。感兴趣的用户可以开始想想这个功能是否对自己有帮助，更多细节描述可以参阅原文 “Keeping secrets in memfd areas”。

关键词: Linux，memfd

为 user namespace 实现文件系统中 User ID 的映射

The idea of an ID-shifting virtual filesystem that would remap user and group IDs before passing requests through to an underlying real filesystem has been around for a few years but has never made it into the mainline. Implementations have taken the form of shiftfs and shifting bind mounts. Now there is yet another approach to the problem under consideration; this one involves a theoretically simpler approach that makes almost no changes to the kernel’s filesystem layer at all.

一直以来都有人建议在真实的文件系统的上层添加一个支持对 user ID 或者 group ID 进行重映射（术语叫 ID-shifting）的虚拟文件系统，这么做的好处是当用户在对下层的真实文件系统发起操作请求时候，内核可以先对 user 和 group ID进行重新映射。这种支持 ID-shifting 的虚拟文件系统主要可用于支持 user namespace，它有许多有趣的特性，其中之一就是对于namespace 内部的 user ID和外部的 user ID 进行映射。通常的用法是使得进程可以在namespace 内部以 root 用户权限运行、而不需要在整个系统全局赋予该进程 root 权限。比如可以配置一个 user namespace 让它内部的 ID 0 对应到外部的 ID 10000，这就是所谓的对 user namespace 实现了 ID shifting。

针对这个想法相应的实现有两种，分别是 shiftfs 和 shifting bind mount。现在有人又提出了一种新的解决方案，这种新方法理论上来说更加简单，基本没有修改 kernel 的文件系统层代码。这组补丁才刚刚发布第二版，可能有许多潜在用户还没有看到它。对 ID-shifting 功能来说，后面的第三版很可能会更加成熟，让我们拭目以待吧。感兴趣的用户可以参阅原文 “Filesystem UID mapping for user namespaces: yet another shiftfs”。

关键词: Linux，UID mapping

自由软件基金会计划今年推出代码托管/协作平台

The Free Software Foundation is planning to launch their own public code hosting and collaboration platform in 2020.

The Free Software Foundation “Forge” will complement their existing and aging Savannah servers used for code hosting. The Free Software Foundation isn’t looking to develop their own hosting/collaboration platform as an original GNU project but looking at an existing free software solution they can adapt for their purposes.

The Free Software Foundation’s lead contender right now is using Pagure as the basis for their platform, but have some reservations over it since JavaScript is required for a pleasant experience. Gitea and Sourcehut are other options they are also exploring but have pros/cons for all of them.

自由软件基金会（Free Software Foundation，简称 FSF）计划在 2020 年启动自己的公共代码托管和协作平台。

自由软件基金会 “Forge” 将结束其现有的已经老旧的代码托管的服务器 Savannah。自由软件基金会不打算自己开发一个托管平台，而是在寻找可以适应其目的的现有自由软件解决方案。

FSF 不喜欢 GitLab，因为它仍然使用 Google ReCAPTCHA 证书方式，自由软件基金会的主要竞争者目前使用 Pagure 作为其平台，但考虑到该方案需要 JavaScript （JS 使用的 LibreJS 是否符合自由软件的标准还不确定），因此对是否同样采用该平台还持保留意见。Gitea 和 Sourcehut 也是 FSF 正在探索的其他选择，它们都有各自的优点/缺点。

关键词: FSF

联系我们

资讯内容部分来自 “LWN.net“。如果您对某些 LWN 文章感兴趣（譬如希望获得全文翻译的）请扫描二维码加微信联系我们：