Omarchy：任何用户进程都可以升级到 root

Omarchy：任何用户进程都可以升级到 root Omarchy 默认 Docker 配置中的一个安全问题意味着，基本上在用户桌面会话中运行的每个程序都可以升级到 root，而无需密码、 sudo 或权限提示。如果您使用 Omarchy，最重要的收获很简单：更新到 4.0.1。视频 我通过项目的负责任披露流程私下报告了这个问题。底层配置已被修补，因此我现在发布详细信息以解释问题所在，并让用户知道更新他们的系统。 Issue Omarchy 将其默认用户配置为 Linux docker 组的成员。这允许用户运行以下命令：无需输入 sudo 。在 arch 上，Docker 守护进程以 root 身份运行并侦听：docker 组的成员可以与该套接字进行通信。 Docker 本身明确警告 docker 组向用户授予根级权限。有权访问 Docker 套接字的进程可以要求 root 拥有的 Docker 守护进程以 root 身份启动容器，将主机文件系统的任意部分挂载到其中，以 root 身份操作这些文件，并以 root 身份运行代码。在受影响的 Omarchy 系统上，这意味着默认用户和该用户会话中启动的所有进程都可以访问 root。概念验证在新的受影响的 Omarchy 安装上尝试读取 /etc/shadow ： $ cat /etc/shadow cat: /etc/shadow: Permission returned 现在观察用户的组成员身份： $ id uid=1000(tester) gid=1000(tester) groups=1000(tester),967(docker),992(input),998(wheel) 现在使用 docker 作为 root 读取受保护的文件： $ docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadow root:$6$... bin:!*:... daemon:!*:... ... 该命令由普通用户进程启动，但实际的文件系统访问是通过以 root 身份运行的守护进程执行的。范围 Linux 补充组由子进程继承，因此这会影响整个用户会话。遍历用户的 systemd --user 实例下方的进程树显示，Docker 组基本上存在于会话中的每个正常进程上。这意味着几乎每个不受信任的代码可以运行的进程都可以获得 root 权限，包括： AI 编码代理和代理利用 Web 浏览器编辑器和 IDE npm 脚本随机开发工具后台进程换句话说，普通用户应用程序的妥协可能会立即成为整个机器的妥协。安全默认值 此配置还有另一个重要方面。这是选择退出，而不是选择加入。用户不必实际使用 Docker。为他们进行了安全权衡，应用于默认帐户，并且没有向用户解释该权衡。安全敏感的默认设置很重要，因为许多用户合理地认为操作系统默认是安全的，并且会通知或提示他们选择不太安全的设置。误导性文档 Omarchy 在其开发工具文档中确实提到了 Docker 组：Omarchy 安装了良好运行 [docker] 所需的一切。这包括 […] 以普通用户而非 root 身份运行 Docker 所需的用户组更改。安全含义几乎与典型读者可能从“不作为根”推断出的相反。阅读该描述的用户可以合理地得出结论，Omarchy 已将 Docker 配置为某种无根模式。事实并非如此。受影响的版本 这会影响 4.0.1 之前的版本。我在最新的 3.x iso (3.8.4) 上测试了它，它也受到了影响。时间表 从引入到解决此问题的提交时间表：更广泛的背景随着 AI 越来越多地针对核心基础设施生成高严重性的 CVE，安全性需要成为所有开发人员（尤其是针对开发人员的发行版的作者）的首要考虑因素。最近，有无数报告称开发人员的计算机遭到破坏，其访问权限被用来污染软件供应链或利用生产系统。开发人员是高价值目标，因为他们经常被授予访问级别。为了方便起见，开发人员计算机通常会禁用安全护栏，将凭据存储在纯文本点文件中，并累积对系统的访问权限。这必须改变。我确信这只是 DHH 的疏忽，因为他们不知道添加 docker 组的含义。在安全方面，没有任何发行版能够做出完美的决策。我对所报告的问题的响应速度感到惊讶，这是一个健康的迹象。也就是说，这并不是我第一次遇到 Omarchy 的安全问题，坦率地说，我不相信决策过程能够确保我的发行版达到我期望的安全级别。我希望这种情况会在某个时刻发生改变，因为奥马奇有很多值得喜欢的地方。 Podman 如果您是 Linux 上的 Docker 用户，并且不想被迫授予 root 权限（即使使用 sudo）来运行容器，那么我强烈推荐