Omarchy: Any User Process Can Escalate to Root

查看原文 / View Original 编辑 / Edit

Omarchy: Any User Process Can Escalate to Root

Omarchy：任何用户进程均可提权至 Root

A security issue in Omarchy’s default Docker configuration meant that essentially every program running in the user’s desktop session could escalate to root without a password, sudo, or a privilege prompt. Omarchy 默认 Docker 配置中存在一个安全问题，这意味着用户桌面会话中运行的几乎所有程序都可以在无需密码、sudo 或权限提示的情况下提权至 root。

If you use Omarchy, the most important takeaway is simple: update to 4.0.1. 如果你正在使用 Omarchy，最重要的一点很简单：请更新至 4.0.1 版本。

I reported this issue privately through the project’s responsible-disclosure process. The underlying configuration has since been patched, so I’m publishing the details now to explain what the issue is and let users know to update their systems. 我已通过该项目的负责任披露流程私下报告了此问题。底层的配置现已修复，因此我现在发布详细信息，旨在解释该问题并告知用户更新系统。

The Issue

问题所在

Omarchy configured its default user as a member of the Linux docker group. That allows users to run commands such as: docker run ... without typing sudo. Omarchy 将其默认用户配置为 Linux docker 组的成员。这允许用户在运行诸如 docker run ... 之类的命令时无需输入 sudo。

On arch the Docker daemon runs as root and listens on: /var/run/docker.sock. Members of the docker group can communicate with that socket. Docker itself explicitly warns that the docker group grants root-level privileges to the user. 在 Arch 上，Docker 守护进程以 root 身份运行并监听 /var/run/docker.sock。docker 组的成员可以与该套接字通信。Docker 官方明确警告称，docker 组会授予用户 root 级别的权限。

A process with access to the Docker socket can ask the root-owned Docker daemon to launch a container as root, mount arbitrary portions of the host filesystem into it, operate on those files as root, and run code as root. 任何有权访问 Docker 套接字的进程都可以要求以 root 身份运行的 Docker 守护进程以 root 权限启动容器，将宿主机文件系统的任意部分挂载到容器中，以 root 身份操作这些文件，并以 root 身份运行代码。

On affected Omarchy systems, this means that the default user and all processes launched in that user session have access to root. 在受影响的 Omarchy 系统上，这意味着默认用户以及在该用户会话中启动的所有进程都拥有 root 访问权限。

Proof of Concept

概念验证

On a fresh affected Omarchy installation try reading /etc/shadow: 在全新安装且受影响的 Omarchy 系统上，尝试读取 /etc/shadow：

$ cat /etc/shadow
cat: /etc/shadow: Permission denied

Now observe the group memberships for your user: 现在查看你用户的组成员身份：

$ id
uid=1000(tester) gid=1000(tester) groups=1000(tester),967(docker),992(input),998(wheel)

Now read the protected file with docker acting as root: 现在使用以 root 身份运行的 docker 读取受保护的文件：

$ docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadow
root:$6$...
bin:!*:...
daemon:!*:...
...

The command is launched by an ordinary user process, but the actual filesystem access is performed through a daemon running as root. 该命令由普通用户进程启动，但实际的文件系统访问是通过以 root 身份运行的守护进程执行的。

Scope

影响范围

Linux supplementary groups are inherited by child processes so this affects the entire user session. Walking the process tree below the user’s systemd —user instance showed the Docker group present on essentially every normal process in the session. Linux 附加组会被子进程继承，因此这会影响整个用户会话。遍历用户 systemd --user 实例下的进程树显示，会话中几乎每个普通进程都拥有 docker 组权限。

This means nearly every process where untrusted code could run, could obtain root, including: 这意味着几乎每个可以运行不受信任代码的进程都能获取 root 权限，包括：

  • AI coding agents and agent harnesses (AI 编程代理和代理工具)
  • web browsers (网页浏览器)
  • editors and IDEs (编辑器和 IDE)
  • npm scripts (npm 脚本)
  • random development tools (各类开发工具)
  • background processes (后台进程)

In other words, a compromise of a normal user application could immediately become a full machine compromise. 换句话说，普通用户应用程序的沦陷可能立即导致整台机器的沦陷。

Security Defaults

安全默认设置

There is another important aspect of this configuration. It was opt-out, not opt-in. A user did not have to actually use Docker. The security tradeoff was made for them, applied to the default account, and the tradeoff was not explained to the user. 此配置还有另一个重要方面：它是“默认开启”而非“按需开启”。用户甚至不需要实际使用 Docker。这种安全权衡是在用户不知情的情况下做出的，直接应用于默认账户，且未向用户解释其中的权衡。

Security-sensitive defaults matter precisely because many users reasonably assume that the operating system defaults to secure and will inform or prompt them to opt-in to less secure settings. 安全敏感的默认设置之所以重要，正是因为许多用户理所当然地认为操作系统默认是安全的，并且会在用户选择使用安全性较低的设置时进行通知或提示。

Misleading Documentation

误导性文档

Omarchy did mention the Docker group in its development-tools documentation: Omarchy 在其开发工具文档中确实提到了 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. Omarchy 安装了运行 [docker] 所需的一切。这包括……为了让你以普通用户身份而非 root 身份运行 Docker 所需的用户组更改。

The security implication is almost the opposite of what a typical reader might infer from “not as root”. A user reading that description could reasonably conclude that Omarchy had configured Docker in some kind of rootless mode. It had not. 其安全含义与普通读者从“非 root 身份”中推断出的意思几乎完全相反。阅读该描述的用户可能会合理地认为 Omarchy 以某种无根（rootless）模式配置了 Docker。但事实并非如此。

Impacted Versions

受影响版本

This affects versions prior to 4.0.1. I tested it on the latest 3.x iso (3.8.4) and it was also impacted. 此问题影响 4.0.1 之前的版本。我在最新的 3.x ISO (3.8.4) 上进行了测试，发现也受到影响。

Timeline

时间线

  • June 1, 2025 — Docker group membership introduced 25799ee
  • 2025 年 6 月 1 日 — 引入 Docker 组成员身份 25799ee
  • June 2, 2025 — Docker group addition temporarily disabled c5ee230
  • 2025 年 6 月 2 日 — 暂时禁用 Docker 组添加 c5ee230
  • June 17, 2025 — Docker group membership re-enabled fdd2aaf
  • 2025 年 6 月 17 日 — 重新启用 Docker 组成员身份 fdd2aaf
  • August 24, 2026 — Docker group membership removed from the default configuration b5ded31
  • 2026 年 8 月 24 日 — 从默认配置中移除 Docker 组成员身份 b5ded31

The Broader Context

更广泛的背景

As AI is increasingly producing high severity CVEs against core infrastructure, security needs to be top of mind for all developers, but especially authors of distributions targeted at developers. 随着 AI 越来越多地针对核心基础设施产生高危 CVE，安全性需要成为所有开发者的首要考虑因素，尤其是那些面向开发者的发行版作者。

Lately there have been innumerable reports of developer machines being compromised and their access used to contaminate the software supply chain or exploit production systems. Developers are high-value targets because of the level of access they are often granted. Developer machines typically disable security guardrails for convenience, store credentials in plain-text dotfiles, and accumulate access to systems. This must change. 最近有无数关于开发者机器被入侵的报告，其访问权限被用于污染软件供应链或利用生产系统。开发者因其通常被授予的高级别访问权限而成为高价值目标。开发者机器通常为了方便而禁用安全防护措施，以明文形式在点文件（dotfiles）中存储凭据，并积累对系统的访问权限。这种情况必须改变。

I’m sure this was just an oversight by DHH not knowing the implications of adding the docker group. No distribution is going to make perfect decisions when it comes to security. I was amazed by the speed of response to this issue being reported which is a healthy sign. 我相信这只是 DHH 的疏忽，他并不了解添加 docker 组的后果。在安全性方面，没有任何发行版能做出完美的决策。我对该问题报告后的响应速度感到惊讶，这是一个健康的迹象。

That said, this isn’t the first time I have ran into security issues with Omarchy and frankly I do not trust the decision making process as it stands to ensure the level of security I expect out of my distro. I hope that changes at some point because there is a lot to like about Omarchy. 话虽如此，这已经不是我第一次在 Omarchy 中遇到安全问题了。坦率地说，我不信任目前的决策流程能够确保我所期望的发行版安全水平。我希望这种情况能在未来有所改变，因为 Omarchy 有很多值得称道的地方。

Podman

Podman

If you are a user of Docker on Linux and don’t want to be forced into granting root (even with sudo) to run containers, then I highly recommend you try out Podman. Podman is daemonless. Your containers run as normal child processes in their own user namespaces and don’t require any sort of root access. I have been running Podman for many months now and it has entirely replaced all of my Docker workflows. I highly recommend giving it a try. 如果你是 Linux 上的 Docker 用户，并且不想被迫授予 root 权限（即使是通过 sudo）来运行容器，那么我强烈建议你尝试 Podman。Podman 是无守护进程的。你的容器作为普通子进程在各自的用户命名空间中运行，不需要任何形式的 root 访问权限。我已经使用 Podman 好几个月了，它已经完全取代了我所有的 Docker 工作流。我强烈建议尝试一下。

References

参考资料

  • Docker: Manage Docker as a non-root user
  • Docker：以非 root 用户身份管理 Docker
  • Omarchy Docker documentation
  • Omarchy Docker 文档
← 返回新闻列表 / Back to news list