Omarchy 默认 Docker 配置中的一个安全问题意味着，用户桌面会话中运行的几乎每个程序都可以在没有密码、sudo 或权限提示的情况下提升到根用户。如果您使用 Omarchy，最重要的收获是简单明了的：更新到 4.0.1。我通过项目的负责任披露流程私下报告了这个问题。此后，底层配置已经被修补，因此我现在发布详细信息，以解释这个问题的内容并让用户知道更新他们的系统。问题Omarchy 将其默认用户配置为 Linux docker 组的成员。这允许用户在不输入 sudo 的情况下运行诸如：docker run ... 的命令。在 arch 上，Docker 守护进程以 root 身份运行并监听：/var/run/docker.sock，docker 组的成员可以与该套接字进行通信。Docker 本身明确警告 docker 组赋予用户根级别的权限。具有访问 Docker 套接字的进程可以请求以根用户身份启动 Docker 守护进程的容器，挂载主机文件系统的任意部分，作为根用户对这些文件进行操作，并以根用户身份运行代码。在受到影响的 Omarchy 系统上，这意味着默认用户及在该用户会话中启动的所有进程都可以访问根用户。概念证明在新安装的受影响的 Omarchy 系统上尝试读取 /etc/shadow：$ cat /etc/shadow cat: /etc/shadow: 权限被拒绝现在查看您的用户的组成员信息：$ id uid=1000(tester) gid=1000(tester) groups=1000(tester),967(docker),992(input),998(wheel)现在以根用户身份通过 Docker 读取受保护的文件：$ docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadow root:$6$... bin:!*:... daemon:!*:... ... 该命令由普通用户进程发出，但实际的文件系统访问是通过以根用户身份运行的守护进程执行的。范围Linux 的附加组由子进程继承，因此这影响整个用户会话。在用户的 systemd --user 实例下遍历进程树显示，几乎每个正常进程都存在于 Docker 组中。这意味着几乎每个可能运行不受信任代码的进程都可能获得根用户权限，包括：AI 编程代理和代理平台、网络浏览器、文本编辑器和 IDE、npm 脚本、随机开发工具、后台进程。换句话说，普通用户应用程序的妥协可能立即变成完整的机器妥协。安全默认值此配置还有一个重要方面。它是 opt-out，而不是 opt-in。用户不必实际使用 Docker。安全的权衡是为用户做出的，应用于默认帐户，并且未向用户说明这种权衡的重要性。安全敏感的默认设置之所以重要，正是因为许多用户合理地假设操作系统的默认设置是安全的，并会通知或提示他们选择不那么安全的设置。误导性文档Omarchy 确实在其开发工具文档中提到了 Docker 组：Omarchy 安装了运行 [docker] 所需的一切。这包括 […] 您需要以普通用户而不是以根用户身份运行 Docker 的用户组更改。安全含义几乎与典型读者从“不是以 root 身份”得出的推断相反。阅读该描述的用户可以合理地得出结论，Omarchy 已将 Docker 配置为某种无根模式。事实并非如此。受影响的版本此问题影响 4.0.1 之前的版本。我在最新的 3.x iso（3.8.4）上进行了测试，发现也受到影响。时间线引入到解决此问题的提交时间线：2025 年 6 月 1 日 — 引入 Docker 组成员资格 25799ee 2025 年 6 月 2 日 — 暂时禁用 Docker 组添加 c5ee230 2025 年 6 月 17 日 — 重新启用 Docker 组成员资格 fdd2aaf 2026 年 8 月 24 日 — 从默认配置中删除 Docker 组成员资格 b5ded31 更广泛的背景随着 AI 不断产生针对核心基础设施的高严重性 CVE，安全性需要成为所有开发人员，尤其是针对开发人员的发行版作者的首要考虑。最近有无数关于开发人员机器被攻破以及他们的访问被利用来污染软件供应链或攻击生产系统的报告。开发人员是高价值目标，因为他们通常拥有较高的访问权限。开发人员机器通常为了便利而禁用安全屏障，以明文形式存储凭据，并积累对系统的访问。这必须改变。我相信这仅仅是 DHH 在添加 docker 组时没有意识到其影响的疏忽。没有任何发行版能在安全问题上做出完美的决策。我对这个问题得到迅速回应的速度感到惊讶，这是一种健康的迹象。也就是说，这并不是我第一次遇到 Omarchy 的安全问题，老实说，我对目前的决策过程并不信任，以确保达到我期望的安全水平。