Omarchy Linux 曝任意用户进程可提权到 Root:Agent 操作系统层的安全隔离新挑战
2026 年 8 月 25 日,Arch Linux 衍生发行版 Omarchy 推送了 4.0.1 版本,这条看似平常的安全更新背后,藏着一项足以让所有 Agent 工作流停摆的严重漏洞:任意用户进程都可以不需要密码、不需要 sudo、不需要任何提示,直接提权到 root。独立研究员 Henry 在其技术博客 0xcc.io 上披露了这一事件的完整经过,而 Omarchy 官方在 GitHub Release 4.0.1 中以"Fast-Follow Fixes"的名义,一次性归档了 11 项安全修复,这条 docker 用户组变更被列入第七项。
要把这件事的影响讲清楚,必须先理解 Linux 用户组的继承规则。Linux 的补充组(Supplementary Groups)会被子进程继承,这意味着任何由用户会话启动的进程,都会自动获得父进程的组身份。Omarchy 在默认安装时把用户加入了 docker 组,这本来是为了让用户运行 docker run 命令时不需要再加 sudo,体验上是顺滑了。但 docker 组在 Linux 上的语义极为特殊:Docker 守护进程以 root 身份运行,监听 /var/run/docker.sock,任何属于 docker 组的进程都可以通过这个 socket 直接与守护进程通信,要求它以 root 身份启动容器、挂载宿主机任意目录、读写宿主机上的任意文件。
把这两条规则叠在一起,结论就变得非常硬:在受影响的 Omarchy 系统上,用户会话里几乎每一个进程——浏览器、IDE、npm 脚本、后台守护进程,以及所有正在运行中的 AI 编码 Agent 和 Agent harness——都默认持有通往 root 的钥匙。研究员 Henry 给出了一段极简的 PoC:在受影响系统上,普通用户直接执行 cat /etc/shadow 会得到 Permission denied;但只要执行 docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadow,守护进程就会以 root 身份把整个根文件系统挂进容器,把受保护的文件内容原样吐出来。整个过程中没有密码输入、没有 sudo 弹窗、没有任何可见的告警,只有一行命令。
这一漏洞的时间线比漏洞本身更能说明问题。Omarchy 的 git 历史显示:2025 年 6 月 1 日,开发者首次在默认配置中加入了 docker 组成员变更;6 月 2 日,这条变更被临时禁用;6 月 17 日又被重新启用——这中间发生了什么、回滚的判定标准是什么、第二次启用前做了哪些安全评估,Git 记录里没有留下说明。直到 2026 年 8 月 24 日,也就是研究员通过负责任披露流程报告问题之后,这条 docker 组配置才从默认账户配置中被彻底删除。8 月 25 日,4.0.1 版本正式发布;8 月 28 日,完整技术细节对外公开。从 6 月 17 日默认配置重新生效,到 8 月 24 日配置被移除,这条漏洞在默认安装的 Omarchy 系统上存在了将近 14 个月。
研究员在博客中指出了一个比漏洞本身更值得讨论的产品决策问题:这是一个 opt-out 而非 opt-in 的配置。用户没有主动选择使用 Docker,也没有主动选择承担 Docker 组带来的安全代价——这两件事都是发行版默认替他做的。文档里那一句"Omarchy installs everything needed to run [docker] well. This includes [...] the user group changes needed for you to run Docker as the normal user and not as root"几乎可以被反向解读为"我们做了 rootless 配置"——但实际上 Docker 守护进程仍然以 root 身份运行,挂载宿主机文件系统、读写任意文件的能力一点都没少。文档的语义和实际行为之间的偏差,是这次事件在工程圈引发广泛讨论的根本原因。
Omarchy 4.0.1 的 Release Notes 一并归档了另外 10 项安全修复,这一密度本身就说明问题:这不是一次孤立的失误,而是开发者向发行版的默认安全姿态提出了系统性挑战。具体条目包括——把 Claude 和 Codex Agent 的启动模式从 full bypass 改为 auto-review(任何 Agent 调用都需要走一道复核闸门,而不是默认放行);阻止视频标题被解析为 Download Video 的播放命令;阻止已安装主题自动执行代码;阻止 FIDO2 配置把认证文件暂存在可预测的 /tmp 路径;把通知点击动作改写为 safe argv 形式,防止命令注入;移除 sudo 锁定的重置命令,避免被滥用为提权工具;守 plugin-add 不接受 git transport-helper 形式的 URL;阻止 USB 设备名称被解析为 Hyprland Lua 执行;在特权 DNS helper 中固定可信 PATH;拒绝不在白名单中的 git transport。这些条目单独看都是常规的安全加固,但放在一起看,它们构成了一套面向 Agent 时代的开发者操作系统安全基线。
值得特别关注的是 4.0.1 Release Notes 里 Claude 和 Codex Agent 的启动模式改动:"Launch claude and codex agents with auto-review instead of full bypass"。这条变更直接对应 Agent 工作流的安全模型。full bypass 模式下,Agent 在用户授权期内可以做任何事,包括执行任意 shell 命令、安装任意依赖、修改任意文件——这对效率是友好的,但对安全是不友好的。当 Agent 进程本来就可以通过 docker 组提权到 root 时,full bypass 就从"Agent 自由度高"变成了"Agent 一旦被诱导,主机立即沦陷"。auto-review 模式要求关键操作走人工复核,这正是当下 Agent 操作系统层最需要的安全边界。
从更宏观的视角看,这起事件折射的是开发者操作系统在 Agent 时代的三重失配。第一重失配在"信任边界"上:传统开发者操作系统假设开发者本人就是操作系统的最高权限持有者,所有工具链围绕这一假设设计;但当 Agent 加入工作流后,Agent 进程继承了开发者的全部权限,Agent 又会调用 LLM、解析外部内容、运行第三方脚本,信任边界瞬间从"开发者本人"扩展到"开发者本人加上整个互联网"。第二重失配在"安全默认"上:开发者操作系统倾向于优先考虑便利性,把很多安全敏感的开关默认开启;Agent 工作流需要的恰恰相反,它需要默认保守、显式授权、最小权限。第三重失配在"可见性"上:普通开发者不会去检查自己的发行版默认把自己加入了哪个组、哪个文件被设错了权限、哪个服务在监听哪个端口;Agent 操作系统需要把这些信息以更高的密度暴露给用户和 Agent,让安全决策有据可依。
研究员在博客末尾推荐的替代方案是 Podman。Podman 是 daemonless 架构的容器运行时,容器以普通用户命名空间中的子进程形式运行,不需要任何 root 权限、不需要把用户加入特权组、也不需要长期驻守的守护进程。从 Docker 切换到 Podman,对日常容器使用几乎没有感知差异,但默认安全姿态完全不同。这正是 Agent 操作系统层应该追求的范式:让安全的路径就是便利的路径,而不是让用户在使用便利功能时被动放弃安全。
对国内企业来说,这件事的启示并不限于"换用 Podman"这样一个具体动作。更深层的启示是:任何把 Agent 引入生产工作流的尝试,都必须先把操作系统的信任模型、默认配置、可见性这三件事重新设计一遍。Agent 不能被简单地"安装"进现有的 IT 体系——它需要与之匹配的操作系统层、应用层、网络层的安全设计。Omarchy 这次事件提醒我们,即使是面向最懂技术的开发者群体的发行版,在默认配置的取舍上也可能犯下影响数月的错误;当 Agent 接管越来越多的日常操作,默认配置的安全性就不再是开发者的个人偏好,而是整个软件供应链的公共安全。
如果企业已经在评估或试点 Agent 工作流,有三件事值得立刻做:第一,审视当前操作系统镜像的默认组成员配置,把任何特权组(除了用户明确申请之外)全部回收;第二,把 Agent 调用工具的方式从 full bypass 调整为需要复核的最小权限模式,关键操作必须经过人类授权;第三,把容器运行时切换到 Podman 或 rootless Docker,避免 docker 组这类默认配置成为整个工作流的单点故障。
Omarchy 在 9 月 8 日发布的 4.0.3 版本中又新增了 OpenClaw 和 Hermes Desktop 两类 Agent 的桌面集成,并继续保留了与 4.0.1 一致的 auto-review 启动模式。从"安全 fast-follow"到"Agent 系统级集成",这个节奏说明开发者操作系统正在主动拥抱 Agent,但它选择了一条以安全默认为基础的路径,而非以便利性为优先的路径。这条路径是否走得通,要看后续几个版本中,默认配置和 Agent 工作流能否持续保持这种克制。
