G.O.S.S.I.P 阅读推荐 2022-06-06

端午节之后，首先我们要祝贺网球传奇——拉法·纳达尔勇夺2022年法网冠军，将自己的职业生涯四大安全会议论文满贯数目提升至22个，我们也希望能早日在四大顶会上发表22篇论文（并且实现双圈全满贯）向Rafa致敬！

看球虽然是四大满贯精彩，但是很多中小型比赛也是很不错的，比如（从前）的上海大师赛，今天我们也为大家推荐一篇来自非四大安全会议的论文A Study of Application Sandbox Policies in Linux，来自SACMAT 2022

这篇论文讨论了最新的Linux发行版中新型软件应用打包格式（例如Flatpak和Snap，虽然社区为不同的打包格式经常吵得昏天黑地）中的权限管理策略。经过作者研究表明，新型的打包格式在安全上带来了新的优势：大部分的应用都在使用新的打包格式的同时启用了最小权限管理策略，限制了权限的滥用。然而，和以前在Android平台应用权限管理上遇到的问题类似，在Linux环境下开发人员依然不太懂得如何正确地配置相关的sandbox策略，导致一定程度的欠保护或过保护。当然瑕不掩瑜，大趋势肯定是逐步走向更为全面的权限精细化管理的。

读论文学知识，读这篇论文首先要学习的肯定是当前Linux应用包管理的一些变化。同大家熟知的rpm（红帽系）和deb（debian系）应用打包不同，最近几年来（其实已经是遥远的2016年了），Linux 社区出现了两种新的应用打包格式——Ubuntu 力推的 Snap 格式和 Red Hat 主导开发的 Flatpak 格式。这两种包格式参考了最近的容器技术，在打包时把一些依赖文件都考虑进去（当然也疯狂吞噬着硬盘！举个例子，Flatpak 打包的 KCalc 在系统上首次安装需要下载 900 MB，而事实上 KCalc 应用本身只有 4.4 MB），同时在设计时均考虑了安全性增强，提供了沙盒隔离的配置选项。有趣的是，Snap 格式和 Flatpak 格式采用的沙盒隔离策略在细节上存在很大差别，Snap 格式更多使用了传统的强制访问控制（MAC）技术作为基础，基于AppArmor访问控制模块来实施沙盒隔离；而 Flatpak 格式更多学习了容器技术，依赖的是Linux的user namespace策略。

受到Android和iOS的影响，现有的桌面发行版的应用也开始要求开发人员配置权限。相对来说，Flatpak 格式要求的权限配置更为底层一些，要求详细声明一些系统资源的访问权限：

不过总体而言，应用的权限声明（及其沙盒限制）基本上都体现在如下五个方面：

在Android、iOS和容器领域，很多论文都做过应用的权限请求分析，即分析到底应用的权限请求是否合理。本文将这项分析扩展到了Linux桌面发行版的应用上，基于如下流程大规模检查桌面应用的权限配置情况：

作者对当前应用商店里面采用 Snap 格式和 Flatpak 格式的应用进行了全面的调查，尽管这些应用的数目（3000多个）远不如Android和iOS商店里动辄百万数量级那么多，但是其中的权限选项相当复杂而特殊，而且不同应用的权限声明大都各不相同，对开发人员来说，配置上还是有很大挑战的。作者执行的分析选取了同时具备 Snap 格式和 Flatpak 格式的应用，通过对比同一个应用在不同打包格式下的差异，来进行初步分析，然后再对结果做一个人工复核。作者发现，得益于新的打包格式的要求，所分析的这些应用大部分都落实了least-privilege原则，除了文件系统的访问不太好事先约束以外，其它的一些权限访问基本上是“如无必要不授权”

在这些应用的沙盒配置安全性上，作者发现有41.7%的 Flatpak 应用可沙盒逃逸，而针对 Snap 的应用则只有9.9%可以做到。Flatpak 格式的主要问题在于很多配置策略没有禁止对用户主目录的读写，导致攻击可能改写重要的配置文件（例如~/.bashrc）。当然，更严重的问题在于开发人员经常声明一些自相矛盾的权限配置，这也导致安全社区经常呼吁开发一些自动化的权限声明工具（然而制定政策这事情，人类多少年都做不好，机器就能做好？）

GitHub：

https://github.com/wspr-ncsu/linux-app-sandbox

论文PDF：

https://www.enck.org/pubs/dunlap-sacmat22.pdf

原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2022-06-06