跳到主内容
@wquguru
精选85Hacker News Best（web_list）行业动态

Omarchy 默认 Docker 配置漏洞：任意用户进程可提权至 root

Omarchy 漏洞：任意用户进程可提权至 root

原文
推荐理由

做 AI 开发环境或关注供应链安全的同学必看，这个漏洞让任何用户进程都能直接提权到 root，赶紧检查你的 Omarchy 版本并升级到 4.0.1。

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.

Omarchy 将默认用户配置为 Linux docker 组的成员。

That allows users to run commands such as:

这允许用户运行诸如以下命令：

代码 · 1 行
docker run ...
代码 · 1 行
docker run ...

without typing sudo.

而无需输入 sudo。

On arch the Docker daemon runs as root and listens on:

在 Arch 上，Docker 守护进程以 root 身份运行并监听：

代码 · 1 行
/var/run/docker.sock
代码 · 1 行
/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.

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：

代码 · 2 行
$ cat /etc/shadow
cat: /etc/shadow: Permission denied
代码 · 2 行
$ cat /etc/shadow
cat: /etc/shadow: Permission denied

Now observe the group memberships for your user:

现在观察你的用户的组成员身份：

代码 · 2 行
$ id
uid=1000(tester) gid=1000(tester) groups=1000(tester),967(docker),992(input),998(wheel)
代码 · 2 行
$ 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 读取受保护的文件：

代码 · 5 行
$ docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadow
root:$6$...
bin:!*:...
daemon:!*:...
...
代码 · 5 行
$ 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.

Linux 补充组会被子进程继承，因此这影响整个用户会话。

Walking the process tree below the user’s systemd --user instance showed the Docker group present on essentially every normal process in the session.

遍历用户 systemd --user 实例下方的进程树显示，会话中几乎所有正常进程都存在 Docker 组。

This means nearly every process where untrusted code could run, could obtain root, including:

这意味着几乎所有可能运行不可信代码的进程都能获得 root 权限，包括：

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

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 已将 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

时间线

The timeline of commits from the introduction to resolution of this issue:

从引入到解决此问题的提交时间线：

  • June 1, 2025 — Docker group membership introduced 25799ee
  • June 2, 2025 — Docker group addition temporarily disabled c5ee230
  • June 17, 2025 — Docker group membership re-enabled fdd2aaf
  • August 24, 2026 — Docker group membership removed from the default configuration b5ded31
  • 2025 年 6 月 1 日 — 引入 Docker 组成员资格 25799ee
  • 2025 年 6 月 2 日 — 暂时禁用 Docker 组添加 c5ee230
  • 2025 年 6 月 17 日 — 重新启用 Docker 组成员资格 fdd2aaf
  • 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. 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.

随着 AI 越来越多地针对核心基础设施产生高严重性 CVE，安全需要成为所有开发者的首要考虑，尤其是面向开发者的发行版的作者。最近，有无数报告称开发者机器被入侵，其访问权限被用于污染软件供应链或利用生产系统。开发者是高价值目标，因为他们通常被授予高权限。开发者机器通常为了便利而禁用安全防护措施，以明文点文件存储凭据，并积累对系统的访问权限。这种情况必须改变。

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
  • Omarchy Docker documentation
  • Docker：以非root用户管理Docker
  • Omarchy Docker文档

更进一步：量化金融体系

看懂新闻只是起点——沿量化金融路径，把它变成能交付的工程能力

进入量化体系 →
话题#Omarchy#安全漏洞#Docker#提权#供应链安全

相似阅读

另一事件，读法相近