2026 年 8 月 28 日，0xcc.io 公布了 Omarchy 发行版的严重设计缺陷。系统中任何用户态进程，都能免密直接提权到 root 级。这个在 Lobsters 上拿下 115 分和 59 条评论的高危事件，起因并非复杂的内核利用。发行版出厂时把普通账户默认加入了 docker 组。
PoC 仅需一行容器挂载指令
在标准的 Linux 权限模型中，普通用户尝试读取 /etc/shadow 文件会立刻收到 Permission denied 报错。但在 4.0.1 之前的 Omarchy 环境里，终端输入 id 命令后，返回的附加组列表里赫然写着 967(docker)。基于 Arch Linux 构建的系统底座上，Docker 守护进程依然以 root 身份运行。该进程默认监听本地的 /var/run/docker.sock UNIX 套接字。
这种本地套接字通信机制无条件信任组成员的请求。攻击者无需寻找内存溢出漏洞，只需执行一句简单的命令：docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadow。参数里的 -v /:/hostroot 将宿主机的根目录直接穿透映射到了容器内部。容器引擎接到请求后，以守护进程的高权限，把系统密码哈希值毫无保留地打印出来。基于本地套接字的权限穿透，让文件系统的读写隔离被轻易跨越。攻击者甚至可以通过追加 chroot /hostroot 指令，瞬间拿到主机控制权的 root shell，随意植入后门。
图：0xCC 演示视频缩略图「Omarchy - Every Process Runs with Root」。来源：YouTube 0xCC
补充组继承击穿应用沙箱
Linux 的补充组机制有个无法绕过的核心机制：父进程的进程凭证会被所有子进程无条件继承。在图形界面启动的生命周期里，systemd --user 拉起的每一个用户级服务，都隐式打上了 docker 组的印记。
这把随时调用 root daemon 的特权钥匙，被塞进了 Web 浏览器、代码编辑器、各类后台守护进程的口袋里。开发者在终端运行第三方的 npm scripts 时，或者拉起包含复杂依赖的构建工具时，这些代码在执行瞬间就拿到了主机最高控制权。用户态应用的沙箱隔离，在系统级的高权限套接字面前形同虚设。将普通账户加入 docker 组等同于授予 root 权限，这在安全社区已经是记录了十几年的常识，而发行版却选择无视历史教训。
当下的开发工作流中，AI coding agents 与 agent harness 框架被广泛引入桌面环境。它们天生需要频繁拉起子进程来执行代码片段、跑通测试用例或构建项目。给这些自动执行非受信代码的自动化实体发一张畅通无阻的提权通行证，无异于在开发机上常态化敞开后门。大模型产生幻觉引入了错误包名，或遭遇供应链投毒，恶意安装脚本就能瞬间拿下整台机器。
14 个月时间线记录架构决策反复
回看 Omarchy 源码仓库的提交历史，这段高危配置不仅存在了长达 14 个月，其间还经历过反复。
| 发生日期 | 代码变更与事件节点 | 影响范围评估 |
|---|---|---|
| 2025-06-01 | commit 25799ee 引入默认加 docker 组逻辑 | 构建新版镜像时埋下隐患 |
| 2025-06-02 | commit c5ee230 暂时禁用该配置 | 发现问题并临时叫停 |
| 2025-06-17 | commit fdd2aaf 重新启用高危配置 | 安全让位于易用性的关键转折 |
| 2026-08-24 | commit b5ded31 从默认配置移除该逻辑 | 漏洞上报后的最终修复 |
| 2026-08-28 | 漏洞走完负责任披露流程后正式公开 | 4.0.1 及 3.8.4 之前版本受波及 |
2025 年 6 月初的短短几天内，配置被引入又被迅速撤下，半个月后却又被再次合入主分支。0xcc.io 文章作者评价这应当是 DHH 团队的工程疏忽，并对上报后的响应与修复速度给予了肯定。作为一个面向硬核开发者的系统底座，核心配置在安全边界上的摇摆不定，暴露出决策流程的随意。这已经是该项目面临的第二次安全事件，开发团队在安全基线上的工程克制力正在流失。
文档误导掩盖配置陷阱
比代码逻辑更具破坏力的是官方文档里的描述。Omarchy 的介绍声称这一设计可以「run Docker as the normal user and not as root」，字面意思是让用户以普通权限而非 root 来跑容器。大多数开发者看到这句话，很容易认定系统启用了安全的 rootless 模式。
实际的工程实现却恰恰相反：底层守护进程依旧是 root 权限，只是放开了客户端调用的门槛。把牵涉系统底层架构的高风险操作，设置为 opt-out（需主动取消）的安全默认值，是一种极不负责任的产品导向。用户在不知情的状态下，被迫接受了一套为了减少输入密码频次而大幅降级安全水准的方案。安全权衡一旦成了强制绑定的搭售品，系统健壮性就失去了讨论基础。
图：0xCC 高清提权演示实况。来源：YouTube 0xCC
Podman 给出非守护进程替代方案
在 AI 模型能够规模化制造系统漏洞的技术节点，开发者本地机器面临的安全威胁已经变了。它不再是内网中受保护的孤岛，而是整条软件供应链上价值极高、防御极弱的突破口。供应链污染攻击的第一波冲击，往往就落在配置松散的开发机上。
0xcc.io 作者在报告末尾给出的工程解法非常明确：转向 Podman 阵营。相较于 Rootless Docker 依然需要在用户态跑一个 dockerd 进程，Podman 采用了更纯粹的无守护进程架构。容器直接作为普通子进程，被强制限制在用户的命名空间内运行。抛弃大包大揽的 root 后台服务，用架构层面的物理隔离去取代基于文件组权限的逻辑校验，是收敛系统攻击面的有效路径。
Omarchy 的风波，是开发者为了桌面便利性强行牺牲系统底座的缩影。操作系统的核心默认值选择拥抱便利而非安全，用户态里的每一次普通操作都会变成悬崖边缘的试探。靠文档说明和开发者的自我约束拦不住失控的提权链路，只有在架构层面锁死权限泛滥的路径，才能保住供应链的基石。
参考链接：
