Omarchy: Any User Process Can Escalate to 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.

If you use Omarchy, the most important takeaway is simple: update to 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:

without typing sudo.

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

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.

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.

On affected Omarchy systems, this means that the default user and all processes launched in that user session have access to root.

Proof of Concept

On a fresh affected Omarchy installation try reading /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:

$ 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.

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.

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

• AI coding agents and agent harnesses
• web browsers
• editors and IDEs
• npm scripts
• 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.

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 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.

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.

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.

Timeline

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

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.

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.

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.

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.

References