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.
More like a company that had hundreds of millions of dollars and a couple decades should have fixed it by now.
If only Podman could beat Docker in advertising…
First they should try making a solution that works as well as Docker. Every time I use Podman or Podman Desktop I run into the most basic problems. Docker works out of the box everywhere.
I don't use Podman desktop but I haven't had any issues at all with basic Podman. It just seems like a better overall design. It would be great if Docker copied the rootless / daemonless approach if possible.
For me the problems are always when I pull some image (like GitLab) and try to get it to work with podman. Or the hoops you have to jump through with podman-compose (user lingering, systemd services, privileged ports (80,443) [yeah I know it's a feature]). Docker just works, Podman (I feel) still requires stuff that makes it less declarative (to get to a running infra).
Still, having a gitlab runner with a docker in docker setup that can access the host docker socket is not something you do lighty, so I am eyeballing buildah etc.
I guess what really grinds my gears is that I'd use podman a looooot more if it could nicely coexist with Docker. I'd use Docker for the big services and podman for all my own stuff. But that is just not possible (at least not afaik), so it is also difficult to switch step by step (yes VMs, bla bla, but it's all complicating).
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.
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.
It might be a mistake but not a serious one, like it's a common setting they had on for convenience of development without being too insecure, but forgot to leave it out of public release.
So there's nothing weird. It being on originally was intentional and not crazy. Only it going all they way wasn't.
> but forgot to leave it out of public release.
They didn't forget. They never knew it was there. https://news.ycombinator.com/item?id=49502099
> 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.
Assuming you mean "they don't actually want to use Arch" as a criticism (rather than a truism), I think that's fair for a distro described as "Arch linux but configured X way". I don't think it's a good criticism for something like SteamOS which is configurable but is aiming hard for "it just works".
I like and use Arch daily. My "way" was just to get past the fdisk squirrel catcher. After that it was as easy as Ubuntu. I'm not bragging, I wish I'd read the manual but was too impatient for that. I suspect I'm not the only arch user that arrived at it using similar approaches. I might even be a target user for DHH's distro but the bloat (and to some extent the vibe coding) holds me back.
> Then they don't actually want to use Arch Linux.
No, they want to use Arch Linux as configured by DHH
Thats the old arch way. New arch is archinstall + AI
Actually we do. I like pacman for example. And don't mind going thru archinstall for a test install once to learn. But my workstation, I'd not like to have to develop, even if I do like configuring minimal installs for other uses like kiosks.
installing arch is enough of a pain that I've been putting off installing it on my desktop for months.
archinstall comes preinstalled on the official iso. It’s a normal install flow and takes 5 mins.
It's something you do literally once.
Yes and?
Yes, and Arch is probably not the right distro for you if you think installing it is a "pain".
What exactly is special about rolling a custom arch in this instance? Like, why does this get so much attention? Do web developers really care about what DHH does that much?
Like, I get it if thats the case. Say, if Chris Lattner or Andrej Karpathy rolled some ML GPU programming distro I'd probably care about it and try and see if it made me more productive.
DHH made Ruby on Rails and lots of people love it (not for me, personally).
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.
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.
> DHH was on the Lex Fridman podcast talking about this recent release of Omarchy in that most of it is "vibe coded".
> He said he didnt review the code line by line, just looked at the shape of it. Whatever that means.
Did... did you even read my comment before replying to it? We know it's vibe-coded, we know it's bash scripts, and we know what it means
Imo they could have sold it like that, in this case. A warning would be in order though.
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.
Ah, the opinionated strikes again.
> 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.
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.
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.
I'm sorry, what?
As an avid Docker user, where should I begin reading about these issues?
Official docs cover those:
https://docs.docker.com/engine/network/firewall-iptables/
https://docs.docker.com/engine/install/linux-postinstall/
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.
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, 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)
>Everybody knows this.
I didn't know this.
Take a look at docker-socket-proxy as a somewhat of a counter to this issue:
https://github.com/Tecnativa/docker-socket-proxy
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?
Absolutely. Docker is a boiling mess of baked-in convenience workarounds (ie vulns). It's an orchestration layer (like k8s with containers), not a real security boundary like VMs. OTOH, single-purpose VMs are basically just as easy these days and those can still pull in containers as needed.
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.
other than what others have said: there's rootless docker too, e.g. as virtualisation.docker.rootless under NixOS. It doesn't have to be this way.
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.
You add yourself to the docker group to be able to use the socket. By default, a uid 0 on a docker container is run as root, regardless of the uid of the owner of the container. That is precisely the issue being discussed.
“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?”
[flagged]
Could you point to things that are not glaring security vulnerabilities that are ridiculed in the same way?
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.
Bun.
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.
> I would almost bet that AI would warn about that.
Exactly. If they had a review process. Which they didn't, at least for that change.
https://xkcd.com/1200/
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.
No, we are judging them by the quality of the work they produce. It is abysmal, yet they persist, so they get ridiculed.
In good faith, show me the nice counterexamples of ai-generated software?
https://github.com/vicrodh/qbz