Hacker News (curated)new | past | comments | ask | show | jobs| show hidden

But, this “vulnerability” is the thing everybody knows about docker since forever. I always make my user part of the docker group, so my NixOS also has this, and any Ubuntu I’ve used over the past year. What is different here?

Start a docker container with the docker socket mounted in the container and now you can have yourself mount / as rw. Everybody knows this. How is everybody so shocked here. Many instructions online tell you to make yourself part of the docker group for convenience (like the digital ocean one).



> What is different here?

I don’t understand how this is a question.

What’s different is that it comes configured this way out of the box, silently, without warning. It’s functionally equivalent to opting in to giving all user accounts root privileges, which is not what anyone expects the default configuration to be.

You can choose to configure your installs this way if you choose to do so. It should not come this way quietly by default.


It does warn you. It's an opinionated Linux for a modern developer/user. This modification absolutely makes sense in that context.

I hope this was an attempt at sarcasm.

The Omarchy team immediately fixed this because it was a security oversight, not an intentional opinionated choice.


Opinionated choice?

I recently used Arch Linux because I have a 4 GiB Mac Air that I want to use for something but it has too little RAM for UI. The installer was user friendly and fast. I got exactly what I wanted.

I don't think that I need Omarchy.

I have only one answer to this:

I'm too old for this shit.


Imo they could have sold it like that, in this case. A warning would be in order though.

There was no oversight and no security. It's vibe-coders pushing unvetted shell scripts and dotfiles.

They "immediately fixed it" after it blew up on X/Twitter. Just like all the other issues they've had in the past few weeks.

And now they formed a "security team" lol.


DHH was on the Lex Fridman podcast talking about this recent release of Omarchy in that most of it is "vibe coded". It is mostly just a bash script to configure Linux, but his approach is interesting.

AI as a core part of the OS that can just change or add anything you want. Linux is great for this because it has access to the source code for everything.

He said he didnt review the code line by line, just looked at the shape of it. Whatever that means.


The whole point of Omarchy is for people who want to use Arch Linux but have it configured the way DHH does.

So I think it's a little different. Anybody using an opinionated respin should understand what they're getting.


> people who want to use Arch Linux but have it configured the way DHH does

Then they don't actually want to use Arch Linux.

The Arch Linux way is to read the excellent wiki documentation, learn about all the choices available, and then make all of those choices so the system is configured the user's way instead of some celebrity's way.


Couldn’t you say that about any Arch spinoff? Seems to be the no true scotsman fallacy.

> Couldn’t you say that about any Arch spinoff?

I can, and I do.

https://wiki.archlinux.org/title/Arch_Linux#User_centrality

> It is targeted at the proficient GNU/Linux user, or anyone with a do-it-yourself attitude who is willing to read the documentation, and solve their own problems.


> Then they don't actually want to use Arch Linux.

No, they want to use Arch Linux as configured by DHH


installing arch is enough of a pain that I've been putting off installing it on my desktop for months.

It's something you do literally once.

Thats the old arch way. New arch is archinstall + AI

The Omarchy team admitted it was a mistake and corrected it quickly.

It’s strange that so many people are trying to call this security error intentional.


I don't think this is as widely known as you believe: I use dockerd via colima so it's not a limitation I've encountered - if I had, I likely would've switched to podman wholesale instead of compromising my system.

Either way though, I would hope it's self-evident to most that taking glaring security holes in a single app (docker) & transforming them into glaring security holes in an entire OS is generally not desirable.


Exposing the docker socket seems like such a rookie mistake to. There's a good reason we've known about docker socket proxies for a very long time.

Also beside that they use ancient package alongside Archlinux. One of those being Chromium. It also used to use Chaotic AUR but now they just automate packages (every 6 hours) in their own repository without any maintainer intervention so it's still open for supply chain issues.


> I always make my user part of the docker group

I don't, and I migrated to Podman because Docker is poorly designed and full of footguns. For example, it it will silently overwrite iptables rules and punch holes in your firewall.


Indeed. Podman works great. And kube play unifies container orchestration by using k8s manifests for local orchestration instead of a separate DSL like docker compose.

This. It’s easy to let happen too. If you’re on a machine that’s not behind NAT then it’s really easy to pwn yourself.

I'm sorry, what?

As an avid Docker user, where should I begin reading about these issues?


> I always make my user part of the docker group, so my NixOS also has this, and any Ubuntu I’ve used over the past year.

You may do that, but I don't. I always use sudo to manage the few docker containers I need, and I prefer podman where possible specifically because I can run it rootless.

If you want to give your user passwordless root for convenience, go ahead, but that should never be the default.


> I always use sudo to manage the few docker containers I need

I'm afraid that isn't really any better. If the attacker is in position to exploit membership in the docker group, he already has access to the user's .bashrc. He can simply write a function called sudo that wraps the real command and records your password[1]. Unless the user always invokes sudo with /usr/bin/sudo, docker group membership doesn't really make a difference.

Once malware runs as an administrator, getting access to root isn't really that complicated. The boundary between wheel and root is more or less security theater.

[1] https://gist.github.com/tokyoneon/34ce1c9e1530a12eb392b1eab0...

Edit: Oh well, I see now that others have made the same point (https://news.ycombinator.com/item?id=49500588). With the same wording even. I'm half-way tempted to delete my comment so as not to look like a plagiarist, but it seems many posters are unaware of the vulnerability, so I'd leave it here.


Does 'chattr +i .bashrc' reliably prevent this? Always seemed sensible to me. Then again, there are a few files getting sourced by the shell and I am not sure I could spontaneously name them all.

The attacker could use `chattr -i .bashrc` with the same privileges before editing your bashrc. A better way would probably be to use `sudo chown 0:0 .bashrc`.

Also you will want to do the same to .profile (because of LD_PRELOAD etc). And also do the same to any directories in your $PATH (~/.local/bin etc)


A distro should be secure-by-default. Omarchy’s design here was insecure by default while the docs have the impression that Docker might be running rootless. Pairing insecure defaults with docs that claim better security is bad.

>Everybody knows this.

I didn't know this.


Do you know about docker compose overwriting your carefully set firewall rules? That’s the other docker thing…

Go on, what other docker things should we know?

Take a look at docker-socket-proxy as a somewhat of a counter to this issue:

https://github.com/Tecnativa/docker-socket-proxy


It depends on what distinction you’re making…

If you are asking concerning security, the answer is that it’s an insecure default that should have protected an unwitting user.

If you are asking concerning consistency with real world situations, then there is no difference and it feels like the fit is over a somewhat controversial figure (DHH) and how he created the distro’s recent release without reading any of the code himself. The counter is that no one installing a distro actually understands how their distro is configured, and trusts someone else’s judgement. Here that judgment was farmed out to AI, and while that is controversial, the uncomfortable truth is that this is how an awful lot of real people are told to configure their Docker installations.

IMO Docker running as a root daemon is a bad idea in the first place and I’d much rather use Podman’s rootless containers.


This. Was also super confused when I saw the post. Like every docker guide literally screams at you when you use rootfull docker. Either add yourself to the docker group with `newgrp` for a termimal session or use rootless docker.

“This house has a hole in its roof but I cut several holes into my roof to water my indoor plants so what’s the problem?”
vga1 5 hours ago [hidden]

People hate DHH and AI, so whatever he does or what is done with AI is ridiculed.

No no, be fair -- some of us ridicule everyone using AI and the slop they get it to extrude.

Yes, I know. That is quite juvenile.

In good faith, show me the nice counterexamples of ai-generated software?

No, we are judging them by the quality of the work they produce. It is abysmal, yet they persist, so they get ridiculed.

Could you point to things that are not glaring security vulnerabilities that are ridiculed in the same way?
vga1 4 hours ago [hidden]

Bun.

His blog posts about immigrants?

You specifically called out security vulnerabilities, but the point missed by the commenter you are replying to is that people who ridicule something originating from DHH or AI are generally not based on nothing. "People just hate X no matter what" is almost always a low-quality complaint, for most values of X.

I've got nothing against DHH or AI. I just don't think vibe coding works well for systems of this scale.

That remains to be seen. The whole concept is still in its infancy. An AI reviewer should have caught these issues when they were PRs.

But you see, it wasn't even a PR. It was just DHH making a straight up commit on the main branch (as far as I can see). With a message "Do all the additional Docker configuration needed". Was it even AI-assisted? At least the commit message wasn't, AIs write smarter commit messages than that.

I said on my earlier comment that DHH and AI get ridiculed automatically because people hate both. That doesn't mean that the ridicule isn't always justified.

https://github.com/omacom/omarchy/commit/25799ee91f54c35e6d3...


Which tells me that they don't really take security seriously because everyone knows exposing the docker socket is dangerous. I would almost bet that AI would warn about that.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact | github