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?
You didn't switch away from windows to get superior software?
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.
While I don't want to discuss the quality of any distro vs Windows, there is a big reason most of us use free software: because it is free.
Whether for you it is because of free as in freedom or free as in beer specifically, quality may not have much to do with it.
In EU at least you can almost get free as in beer Windows, you can buy a fully legal 2nd hand (resold) Windows license for about $10, the price of a fancy beer.
My reasons to switch to Linux from Windows were very little about "security" and plenty more about freedom. Sure, it was very nice avoiding running an antivirus, but that was just the cherry on top.
I wanted the freedom to change and "rice" my desktop however I wanted, and the Compiz cube looked awesome. I found Windows condescending and restricting in that regard. Yes, my first reason was the aesthetics, kick me out of the nerds club. (That was also the reason I switched to Mac for 10 years).
My second reason was that I suspected I could learn so much more about computers using Linux full time. And I did.
I was also younger and used to associate Windows with soul-sucking corporate jobs and Linux with new ideas and experimentation. It was us-vs-them. Open Source vs Micro$oft and all that vibe.
I'm sure "superior software" is true for most, but that's a much wider goalpost than the people specifically worried about security/vulnerabilities. One of the biggest factors pushing people to Linux lately is the increasing number of ads and annoyances being crammed in to Windows. Security has been moderate for a long time.
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.
Well the whole point is to have a good foundation and then make it actually yours, and the only necessary key binds are probably SUPER+K for the key bind cheatsheet and SUPER+SPACE for the menu.
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.
Hey, do you have any concerns about malware, in case of using the plugins or themes from these websites ?
I was a bit skeptical, considering all the malwares that are being found in the package managers and plugins are pretty much the same thing but as extensions.
It is kind of nuts how little attention this more-than-controversial-enough aspect of it gets compared to anything else, to the point people don’t even know this about it.
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.
Can you say what you prefer? I'm always down for alternative UX flows and with hyprland being so user specific it's hard to see how people leverage it across the spectrum.
I just switched over to it from Ubuntu. So far the nice thing is that it gives you a fully decked out hyprland setup without any of the hassle and pretty good UX.
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.
Github is awash with people's dotfiles including fully featured DEs built on top of things like Hyprland and Noctalia, and they don't require you to use a mess of a distro to use them.
> No need to use a whole distribution with 1000 other poor decisions made for you.
I used Vim for a decade (and Linux for much of that time) and the constant tweaking and changing things drives you mad after a while. The more you invent it yourself the more it changes. This is why I prefer MacOS+VSCode these days, which comes with good defaults and simpler VIM-style bindings.
Omarchy sounds like those popular vim configs such as https://astronvim.com/, which I also tried using and also ended up heavily customizing myself. It provided some nice defaults as a baseline but was ultimately comes with too much hyper-customization (which has a lot to do with vim/neovim trying to act like other more modern editors).
Yeah, I mean when I set up my last distro I just installed claude and told it what I wanted and in about 30 minutes it was up and running. No need to install random distros!
The nice thing about wayland is you can easily combine a compositor/window manager with a wayland desktop shell and get a lot of the stuff you used to have to fiddle with when using like i3 for free. For example, I use niri with the “dank material shell” desktop shell and get status bar, notifications, clock, suspend/resume, etc. all “out of the box.”
I got here because it was the first time I saw a tiling window manager on an Omarchy video. I was on windows my entire life, so when i saw it and how bad windows got, I decided to give it a try. A few months since I de-omarchyfied the system and went straight back to arch. And now still on it.
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 for one hold out for them releasing an optimized XFCE variant - don't by any means dislike keyboard driven software but I like it as an extension of a regular functional UI experience not as a "argh the windows are stuck in xyz pattern until I re-remember xyz combo"-experience: the UI surface is not the speed limit in my optics, rather it is the apps I use or (increasingly due to local AI) the computational hardware limits of my machine.
There's definitely appeal in key-driven window managers in general. Projects like i3 and Niri are popular. But you can get that with any Linux distro (albeit not many have it set up that way by default). You don't generally choose a distro just for whatever DE/WM it happens to start with.
Being hyprland keybinding skilled removes a lot of the desktop interaction surface, it's a worthwhile investment. People who've used tiling window managers for a while will tell you that it gets natural at a point, then a whole class of friction that normal WMs cause just goes away.
What I don't get is that VS Code has solved this perfectly via the command palette - you just bring up the prompt and start typing and it will find you the command you actually need without having to memorize anything.
There's a segment of people who are into customizing their desktop environment as a hobby and end in itself.
Personally I've never really been into it, and these days I have a broad and revolving set of machines I have to use, so this sort of thing is absolutely not worth the bother. I just install KDE Plasma and use the computer.
I recently customized my own Bazzite install to use hyprland plus other customizations, there's really not much different than what omarchy did. It's pretty much that with some pre installed apps. Anyone that gave them funding is an idiot IMO.
Then it's not for you, or you can't vision how 5 minutes of learning can save you hours of future time.
Having to know like 5 keybinds and no taskbar is absolutely the point and it's a beautiful concept of how to use your computer. And it works, if you are open to relearning just a bit.
This seems to be quite contrarian considering we had this on the front page of HN the other day: "Debian votes to allow "responsible use of generative AI".
I guess this LLM coding wasn't "Responsible" enough. hahaha
Omarchy is all in on AI, if you look at the recent commits and the dev workflows they have set up you can easily tell no human is looking at all the stuff they are merging.
It's not the same thing as allowing some AI contributions under strict guidelines.
Even worse. They don't even have AI review them. I fed the commits that introduced the problem to a few frontier models and they saw several problems, including the aforementioned security problem. Even Mistral saw it. I did have to instruct all models to look for security problems, though, but still.
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.
On Lex Fridman recently DHH was enthusiastically bragging about how he was letting AI generate C++ that he intentionally wasn't even looking at, he was treating it as a pure black box and just submitting the output.
"Someone" didn't find that, AI found it. So it's not clear what your point is about vibe coding. Would humans have noticed this problem, especially given that it's not remotely exploitable? (you have to plug in a malicious USB device).
The fact comments like this get downvoted because what they say is inconvenient is one of the major signs AI has fundamentally broken HN.
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.
HN has been fundamentally broken for a long time, there's nothing new or special about AI. It just joins a loooong list of topics where people abuse downvotes and flagging to punish people they disagree with.
Ironically, the right fix is to replace human moderation with AI. Every so often I think about creating an HN or old-Reddit style discussion website that gets rid of user driven moderation entirely in favour of "polite but free speech" rules, assessed by LLMs on the fly, along with ways for users to label comments with various adjectives for both their own filtering and training a RecNet. A bit like a mashup of Reddit, HN, Slashdot and new ideas.
Doing that from Europe is tricky due to the lack of the first amendment, but could be worth a try anyway. It could probably be sold to an American if local laws become too difficult.
Yes. An additional reason is that both X and Reddit are no longer viewable without logging in. This might attract readers, though perhaps not posters, who need to log in anyway. But your free speech rule might make the forum one-sided over time because users whose views are excluded elsewhere would concentrate there.
It’s that age old “start a docker container with the docker socket in the container and you are effectively root”. What are we talking about here? This is not new?
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’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.
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.
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.
> 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.
> 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".
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.
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.
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.
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.
He leveraged his past success as a web developer to get into online culture war punditry. Now he's a prominent race-baiting reactionary.
There's a sort of cult of personality around him at this point. His acolytes follow him for his nativist views, and then adopt his technology unthinkingly.
I don't know why my comment was downvoted above. This isn't a serious distribution and you shouldn't expect it to be. It's a vanity project of a niche alt right tech bro, and this is the level of rigor you should expect.
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).
> 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.
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)
> The attacker could use `chattr -i .bashrc` with the same privileges before editing your bashrc.
No. Setting flags requires root privileges, sudo was implied. At least on my system.
> Also you will want to do the same to .profile (because of LD_PRELOAD etc).
Yeah, that's what I meant with additional files sourced by the shell. I knew about .profile, but I am not sure that's all of it. I think different distros may be set up differently in this regard. Also I am pretty sure, you can define function overwrites/aliases and execute code in any file getting sourced, it's not just LD_PRELOAD attacks.
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.
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.
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.
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.
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.
Unfortunately, it's hard to classify something as a "rookie mistake" when the developers behind the most revolutionary enterprise tech in the world have accepted it as "by design" & just put a hard-to-find disclaimer about it on one single page of their dense docs.
It certainly does help quell imposters syndrome whenever it creeps up on my though.
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.
> But, this “vulnerability” is the thing everybody knows about docker since forever
OP’s point exactly - it seemed somehow in their vibecoding workflow, they forgot to even do a human architectural sniff test for the stuff everyone knows. It reflects very negatively on them.
On the flipside, once you use an OS that is totally open to agentic stuff, there's no going back really.
I can open Pi and ask it to fix some window tiling issue, help me install shortcuts, help me figure out how to install flatpak vs appimage, etc. the list is endless. I cannot see myself going back to a legacy OS unless I'm forced to by my job for compliance reasons.
Why is the list endless? I don’t even remember the last time I check or change any on my mac settings. And my unix things haven’t been touched in months. My debian server is basically frozen at this point.
That’s like one of two lines of i3status. Awesome if you need something like this one and built it. But don’t pretend that there aren‘t myriad solutions out there that have solved a lot of possible use cases.
UI is desktop environment and (usually) ports to large-use distros cleanly.
- 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 run Niri and Dank Material Sell on Fedora. It’s perfect, and better than Omarchy from what I’ve seen. I much prefer scrolling window managers to tilers.
Yup. I've been on zirconium (https://github.com/zirconium-dev/zirconium) for a while, and it's great. Fedora atomic/bootc under the hood with Niri+DMS. Basically bombproof.
Fedora (or debian, or archlinux or whatever distro you choose) doesn't force you into an UI. All of them have minimal, server and/or "flavored" versions and you can always uninstall and install whatever you want.
You still have to use rpmfusion, which isn’t a huge deal. It’s maybe 5 min one time and then you are set.
Or you could use one of the Universal Blue spins. Bluefin and Aurora have non-free stuff built in and you can install pretty much any package from anywhere.
Counterpoint: I've had very few (and always minor) problems upgrading between major Fedora releases over the years with no more effort than following the well-documented steps to do so, including both traditional and atomic variants, the latter with a wide variety of layered packages as specifically not recommended due to potential problems when upgrading.
And on the server side of things, I ran a Fedora CoreOS VM with a Pihole container that silently and successfully auto-updated both the OS and the service container for years with no intervention on my part.
I had to support fedora on desktop and laptop for a large company.
Worse, it wasn't my job to support those machines, its just my department needed cuda and I was the slowest person to run away when they called for help.
I think this is more about the UI, rather than the install. I haven't tried it myself though.
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).
Even if you introduce bugs in your UI (which I think is not very likely if you have a basic understanding of your system), the chance that someone would exploit software that literally only runs on your own machine seems extremely unlikely to me.
The old human nature tendency of "Just ship it!" and the desire to move on to the next shiny thing on our wishlist doesn't go away with AI. If it anything, it makes it worse.
Yeah, I could literally open up a port on my computer which executes everything sent to it. As a bespoke app, it's pretty unlikely that it would ever be exploited even though it's ridiculously dangerous.
To be at risk, you'd first need to publish your application. The attacker would separately have to figure out how to identify and access your computer for attack.
Add that annoying theo guy to that list. Cant stand these people, they confidently push out videos like they're experts, a week later it turns out whatever they were talking about was total crap and they've already abandoned it - case in point OpenClaw. Look at the mess of videos those named above put out about it, not a single one uses it anymore.
There is only so much a human can master in his lifetime. And if you choose to master the art of video production, then you are probably not spending that much time on mastering the thing you yap about on camera…
> if you choose to master the art of video production, then you are probably not spending that much time on mastering the thing
What?
Its perfectly possible to master two things. Video production isnt _that_ hard. Especially as lighting, shooting adding graphics and editing film is much much easier than 10 years ago.
I was watching one guy explaining the xv6 code and it was pretty much one shot with a single camera pointing at the listing on paper. Not sure if you need professional video if you want to really expound on something.
Sadly, true. I know a person who gets AI news from that YouTuber and quotes him like he’s a household name and pays him for some repackaged chat models. It’s tedious and hard to talk to them about basic/remedial aspects because their education from YouTube is half-heard and superficial. I’m trying to get him to invest the time in hands-on experience and then we can talk about that. When you’re deep into these channels, you’re not gaining experience and you can’t easily start until you pull away.
> they confidently push out videos like they're experts, a week later it turns out whatever they were talking about was total crap
100%! When the US attacked Iran, they became experts on wars; when Iran closed the strait, they turned experts on foreign policy, diplomacy, and negotiation; they were doctors during COVID; now they are SME in flooding and disaster control after the Nepal incident.
It’s sad, but a lot of software folks have decided to become influencers and not pursue expertise. I remember before you’d mostly be reading boring looking blogs to follow experts in the industry. It seems like the mindshare has moved to flashy videos by people that aren’t experts, but are great at communication. Similar to how if you want to watch some diy video on YouTube, you’ll get much better information from a poorly produced snd edited video from someone that knows what they’re talking about vs a well produced and edited video from someone that has no idea what they’re talking about.
I don't think I've ever actually seen a theo video, but I stumbled across this and think I've seen all I need to know. 3:45 even references your criticism.
Omarchy imo is best for agent maxxing Mac power users who aren't locked into Apples proprietary apps like Final Cut, audio production software or Adobe and Affinity, so maybe not so great for designers and photographers as the main system.
No harm, no foul izacus. I am laughing inside because I'm included in the "angry" group by default (I hate all Linux distros, less than Windows or MacOS) and I'm often a basic docker user but got over major DE customization like Omarchy when I needed to get thing done at a higher rate (back then the coolness was crunchbang).
I had just enough issues with archinstall the last time I tried it that I went back to EndeavourOS which essentially gets you a GUI installer and some pre-installed utilities on the stock Arch install. The only significant change I'm aware of is that they use dracut instead of mkinitcpio.
I think I get your point as omarchy represents a different kind of UI, but if it was just about getting a rock solid stable working environment, Fedora or Ubuntu with either Gnome and KDE work perfectly fine. I don't even use a third party terminal (just konsole). Keyboard driven terminal workflows works fine on KDE for me.
The problem is not the hype, the problem is that it's a vibe coded distro. AI lowers the bar substantially in terms of needed competence and diligence to create something like this. Of course bugs and issues are present in human created software as well, but now that everyone can vibe code a distro the chances of low quality software are much greater.
Linux isn't like macOS, it doesn't have any kind of proper desktop sandboxing architecture that really works. So this is kind of security theatre. If you run a malicious program it can do stuff like tamper with your PATH or exploit local vulns in apps to get to the point where it can control anything that matters (which root generally doesn't). For instance it can just drop a custom shell into ~/.bin/.hidden-shell and reconfigure the terminal emulator to run it.
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.
Bubblewrap is a less powerful version of sandbox-exec, but the macOS architecture is much larger than just that. In effect macOS runs everything under bubblewrap, in such a way that users don't notice but apps are meaningfully sandboxed and root exploits barely matter.
It respins UNIX security in favour of a mix of SELinux and a (mis-)use of UNIX user/group identities to contain apps instead of users. Linux distros sort of do that too but only for system services, whereas Android does it for user visible apps.
> Linux isn't like macOS, it doesn't have any kind of proper desktop sandboxing architecture that really works.
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.
There can be exploits in any security system but the architecture is sound. There's no equivalent of TCC on Linux (I mean one that really sticks), and no easy way to create one.
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).
Mac users always like to defend some of the things Apple legitimately got right over most Linux distros, but always ignore that supply chain security and standard package management security on Apple (Homebrew) is akin to giving a bunch of internet randos root access to your machine with no oversight, vetting, or code review of any kind. At least most Linux distros do basic package signing.
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.
Homebrew isn't standard package management on macOS. It's an aftermarket mod that Apple didn't have any design input to at all, and which largely imports the laissez-faire Linux approach to packaging to an OS that has a totally different design for native apps.
> 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.
It should be the other way around. I'd be extremely careful before allowing anyone to manage prod from anything other than a Mac. Apple has an OS design that can be solve many serious supply chain and credential stealing attacks. SREs don't maximally exploit it today, and Apple only focuses on consumer use cases so they aren't going to use it to solve server management problems. I think there's a business opportunity in fixing that. But Apple has put in place all the infrastructure you need, whereas the Linux community simply hasn't.
Unfortunately one I have never seen a MacOS production engineering guide that does not say "install brew" as like step one, exactly because Apple failed to provide a software suite sufficient to meet developer needs on par with that of major linux distributions. Macports is at least maintained by current/former apple employees and signs their packages, but in practice no one knows macports exists.
> I'd be extremely careful before allowing anyone to manage prod from anything other than a Mac.
I would never even consider letting anyone near production Linux servers if they are not comfortable enough to maintain and secure Linux on the computer in front of them.
> I think there's a business opportunity in fixing that.
Ah, neat. I did something like Caution a few years ago but for Intel SGX, called Conclave. It made it much easier to deploy apps to enclaves, get remote attestations and communicate with them securely.
Unfortunately it's a difficult space to work in. SGX tries to remove the kernel and hardware from the TCB but there are a lot of obscure attacks to do with tampering with the enclave's sense of time. It's not an SGX problem, it's inherent to enclaves not having enough trusted hardware like signed clocks, tamper-resistant counters and so on.
Also the programming model has to be adapted but most customers just want a button to click for a box to tick, then they can say they're protected. Very few want to change their app architecture to be more secure.
Homebrew is far from ideal, indeed, but MacOS was never really marketed as an OS for people to manage remote server clusters. If you stick within their designed ecosystem and only do software dev for native Apple desktop/mobile apps using XCode, then you don't need homebrew.
> It's not an SGX problem, it's inherent to enclaves not having enough trusted hardware like signed clocks, tamper-resistant counters and so on.
Those things all exist now in several forms. You were just too early! (I know the feeling from past companies). SGX is a giant pile of design flaws I abandoned pretty early, but _TDX_ is what SGX should have been, and AMD sev-snp is wildly ahead allowing hardware memory encryption between different nested protection rings.
Back before these nice things, I co-designed custom hardware security modules, which was my "do things that dont scale" period.
> Also the programming model has to be adapted but most customers just want a button to click for a box to tick, then they can say they're protected. Very few want to change their app architecture to be more secure.
None of that is required anymore. With our design it is no harder than using Heroku. Bring the code you already wrote. Enclaves run hardened Linux kernels. If it can run in a container it can run on Caution.
> Homebrew is far from ideal, indeed, but MacOS was never really marketed as an OS for people to manage remote server clusters.
And if people on macs stuck to media work, we would have no issues. My rage comes from most sysadmins in silicon valley using homebrew/macos to ssh to production machines full of user data, and sometimes with billions of dollars in value attached. That is when I go into BOFH mode and start revoking access credentials.
> 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.
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.
The right right question would be: why aren't we enforcing a document to be self-contained? Why are documents agents? Why can any document access anything or indeed, do anything? That's not a document, that's a program!
I need to write a proper introduction to macOS security because this thread has lots of incorrect assumptions about it!
macOS doesn't determine once whether Word can read all your documents. That's the sort of policy that applies to non-native Mac apps. Word is a native Mac app built according to Apple's design specs. Like the rest of the Office suite it opts into the stronger "app sandbox" feature macOS offers. That means:
1. It can only read files that the user granted specific access to by opening them with the system file picker. This grant is persistent across app restarts, upgrades and file moves, but is fine grained.
2. Its own files are protected against tampering from other apps. That means not just the app's binaries (which are protected in all cases regardless of app opt in), but also its own data files stored in $HOME too, like download caches. Obviously its address space is fully protected from debugging APIs too.
So if Word is compromised by a macro virus or buffer overflow, or whatever, that code is very constrained. It can't steal your SSH keys. It can't tamper with your ~/.bashrc. It can't tamper with your operating system, or escalate to root, or phish any credentials from you. Despite that, Word has all the functionality users expect.
Additionally, if you download and run malware, that malware can't edit the configuration of Word to inject macros, and if you store files in Word's protected area they can't even read those files.
MacOS only falls back to coarse grained permissions for looking at certain sub-folders of $HOME when apps bypass the native Cocoa APIs, e.g. by using open() and readdir() directly. This usually means some dev tool or script that was written with Linux in mind.
All this is possible because the kernel has very sophisticated support for app identity and security. It's exactly what you're asking for, and what Linux has failed to provide. You can open a file in Word thus granting Word access to it without even realizing you're doing it, then upgrade or downgrade Word without it losing access, move those files around, move Word around, download a beta version from some internal MS server and have two versions installed at once, etc. It's all possible because of sophisticated kernel level support working in close tandem with a lot of userspace infrastructure which is missing on Linux.
Re: entitlements. Apple's system allows entitlements to be self-declared, or granted by Apple, or both, or granted by non-Apple authorities if the OS is so configured (this latter fact is documented but obscure). MDM, app stores and anti-malware systems exploit entitlements aggressively to understand what apps can do. Their system allows a pretty complex ecosystem to develop where users can delegate trust as much or as little as they like.
> 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.
How is that different from creating a new user to run that script? This has been the standard practice on Linux for decades, and it is how I run tools like Codex and Claude on my machine. I wouldn't allow AI tools access to files, mount points, etc, owned by my main user.
This works best for terminal apps; for GUI apps such as Steam and games where running a separate graphical session isn't practical, you can use bubblewrap.
The obvious difference is that you have to create that other user (as opposed to denying the ~/Documents request). Also when you curl|bash you normally want to install under current user -- not something you're supposed to do on Linux.
I don't actually believe that macOS protects me here, as I granted this permission to the terminal five years ago...
Its opposite. Windows and MacOS lacks proper sandboxing. While openbsd has pinsyscalls and linux has seccomp-bpf. Windows and MacOS only have filesystem and worse version of user namespace sandboxes, anything else and you need to write a kernel extension or rely on a hypervisor.
> Unfortunately implementing an Apple style architecture on Linux would be very difficult.
The apple apps kind of thing already exists and its called flatpak.
Windows has virtualisation based sandboxing and NT has object-level security (albeit not often used correctly and granularly) and macOS has (among other things) SIP and a subsystem called sandbox that does exactly what it says: it sandboxes. It can sandbox in comparable namespace terms (like cgroups v1 or v2, but more in translocation style execution since it's a MAC framework) yet it also does it a much more fine-grained level depending on what you need. It is used by launchd and applications by default, some entitlements require it so if you want to do some broad kind of elevated application, you also have to have a specific sandbox profile. It's also been around for 16 years, and comes with a ton of examples if you wanted to use it yourself to constrain some process. Yes, it can do filesystem (would be pointless without it), but also does ipc, io, network, memory, fcntl, sysctl, mach ports, sys calls, processes, ui, sockets, messaging, events and all of that including context-aware filtering and compound matching for all of them. And if that's not enough there is also ESF and NEF, the latter only working on networking. You can compare those two to eBFP LSM and XDP. If you want all of this on linux, you'll need to add a lot of custom eBPF and LSM as well as always run in a hypervisor for guaranteed IOMMU usage, but you can't use bare KVM for that either, so you'll either need to never touch the privileged kernel (not even give it a console) or you need to run Xen and use XSM.
Flatpak is just a cheap container copy. Can't do anything beyond what cgroups and things like apparmor and selinux can do, and uses a runtime to do soft higher-level policy functions that translate down to the same primitives. If anything, it's a great bundler, but doesn't do anything new policy-wise.
So, can you get the macOS-level capabilities (both low-level and higher abstractions)? On Linux, yes, but they don't exist yet. On Windows: technically possible, but since that would break most GUI workflow it's not likely that anyone is going to bother, and you're going to have a hard time recompiling windows yourself to make that happen.
Hello, can you tell me if I can filter syscalls made from a memory address in macos without virtualizing the process, or requiring special entitlements and root? I currently have a project where sandboxing is important and i need to prevent all syscalls from a region. This is very simple in linux, and on openbsd i dont have to do anything because openbsd by default does not allow untrusted callsites from making syscalls (and the region in this case is not loaded by openbsd's dynamic loader).
On macos i currently virtualize the process itself, but this has virtualization overhead and some emulation overhead because macos does not let you map all the host process pages to a guest.
I don't think so, the XNU and macOS LS architecture doesn't assume you're going to do policies based on the internal memory topology of a process. It's usually done with multiple processes and having one be very constrained doing only some very specific calls and the other not being able to do any calls at all.
You can probably get by with mprotect or mach internals, but if you're developing at that level you've probably already either implemented or dismissed that.
It's a bit of a different architecture with PAC/MIE/APRR (and to a degree AMFI) being used to prevent abuse that would require syscall filtering in the first place. While I personally don't think that's airtight, it does appear to work out well for their ecosystem.
Edit: come to think of it, region-based call filtering is never really going to be enough on its own, if you don't combine it with other techniques it's basically a rop gadget fest. Probably also why SBX went for intent rather than trying to do it based on location/origin.
macOS absolutely has sandboxing, what are you talking about? But the reality is that you need custom sandboxing tools less when you don't have basic problems like "anything that runs ever can read my ~/.ssh directory without problem" or "you can hijack my password by interposing sudo and thus do anything". This does not matter because macOS will see a program signed by Corp XYZ is trying to read data not owned by that cryptographic signature, and it can't escape the code signature check, and it will flag it. A program cannot simply read your password from stdin and elevate privileges silently, because granting new privileges requires communicating with a higher privilege program so it can delegate to you, and that program has a non spoofable prompt. And so on.
You can use Linux's sandboxing functionality to make a pretty hardened server. If you take in mind the physical deployment and go the extra mile, it can be very secure. The Linux desktop is not and will never be secure in its current form from things like extremely basic local malware. You would have to redesign much of the desktop stack from the init system downward so you could easily do things signature-based identity, proper per-identity secure storage and key management, securitizing elevation of privileges, getting rid of setuid, etc.
This isn't the case at all. Please learn about Apple's security architecture before making sweeping claims like this, it is very deep and has nothing to do with user namespace sandboxes. Windows also has a sandboxing architecture, it's just not as good as Apple's.
FlatPak's security architecture is an attempt to sort of head in the same direction, but they are a decade+ behind and will probably never get there.
Sigh. Qubes had some great security design and implemented it the only way time/funds would allow: by cobbling together a lot of unfortunately very complex and broken things built for a different security model decades ago.
Qubes is the least bad option for laptops (until Stagex Work ships which I am designing) but there is no reasonable server OS.
what are you on about? The fact Qubes has to exist proves Linux is insecure. QubesOS is not a Linux distro. It just happens to ship dom0 as a Fedora VM. But it doesn't just support Linux, it also supports Windows and BSDs. None of Qubes security guarantees come from the Linux kernel.
The issue is not that Linux lacks a central authority that holds some encryption keys and controls what software you can run.
The issue is that you should not run any software from a source that can't be trusted. When we used to run only software from community distros or that we compile ourselves, launching a malicious program was a non issue.
You do realize you can do the exact same thing on macOS? Just alias sudo to whatever you want. BSD I assume you can do the same with doas.
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.
You're making a big assumption about how other people use their computers. If you're running mostly desktop applications on Linux, you wouldn't use sudo much either. And if anything, I use sudoish-to-actual-rootlike on Windows more than on Linux, because more things are gated behind elevated privileges (some papered over by default UAC settings, but only when manipulated through built-in GUI tools) and there's nothing as simple as Distrobox and rootless Podman to set up isolated non-root environments.
Any user process can append anything they want to your shell rc (.bashrc, .zshrc). In this case, they added a bash function for a fake sudo prompt. It then uses the password the user entered to run a malicious payload as root.
The freaking point is that basically anything worth running will have that amount of access, even Flatpaks. And you don't freaking know what's malicious before hand.
I think that depends on your point of view. I wouldn't run a program on my computer unless I were sure that it's not malicious. And if you mean that some program I already trust could be exploited, that's true even for the Linux kernel or any sandbox / security solution you would come up with. I'm not denying that there's always a risk, but there's nothing good in running arbitrary code that you can't trust.
It’s not, but the grandparent does point out 1 major flaw with sudo being a typically command that goes through normal path discovery. It makes it easier to escalate from a compromised user account to a compromised root account, since the end user is likely to type the root password into a command that can be shadowed in their user space.
You need root in order to overwrite sudo in the first place I think, but yes password replay attacks are real. 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. You don't even need a password at that point. Unfortunately haven't figured out how to make this work over SSH.
Look at the excerpt. They're not overwriting the sudo binary. The attack vector is real for malware running on a administrator user session which can be escalated to root via sudo.
It's a niche, but it's real. Esp. if you're targeting npm installed user scripts or similar
You do not need root to run that shell function, nor to get it loaded into a shell's environment.
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.
I was also unable to find any Flatpak that has access to the home directory when installed, you may well be right but I couldn't find any. I used Flatseal to verify the permissions: https://flathub.org/en/apps/com.github.tchx84.Flatseal
I'm also of the opinion that we generally shouldn't use software that we don't absolutely trust. That has kept my .bashrc (and other files) safe so far.
To be fair it's possible the situation has changed since I last checked. But at least it used to be this way (https://flatkill.org/2020/). I'm glad the situation has improved in terms of security, but I'm still not a big fan of the flatpak design as a whole.
There is. Simply do not install sudo and do not allow access to root at runtime. I am serious. There is absolutely nothing you cannot run unprivileged these days. Can even run sshd from a systemd user unit in your home folder, and even assign port 22 to it if needed with Linux Capabilities.
You do need some root process to be able to write the updated kernel image to a root owned directory. On macos that is presumably their update daemon, while on something like ParticleOS[0] IIRC it is the systemd-sysupdated daemon, though I don't know if you can initiate the update as an unprivileged user or if its done on a timer or only root initiated (sysupdate has had a lot of changes not too long ago that reworked it extensively. It use to be something only root invoked transiently with a possible timer to "update all", but now it has a full on daemon).
Basically the reason we "need sudo access" (or anything to elevate privs to root) is because how the system is architected and changing that is mostly only possible on new distros which can decide to change the architecture.
On a modern Linux system you do not need sudo to compile software, install it, or even run it as an unprivileged system service in a User Namespace bound to port 22 (if you give your user the correct Linux Capabilities).
The only thing you cannot do as an unprivileged user is update kernels, but that requires a reboot anyway and the risk of letting an unprivileged user do that is mitigated with hardware enforced secure boot.
Most distros are holding onto 90s designs that are very hard to change once established.
Did you actually try or are you provocatively speculating?
I do have non sudoers groups devices and I also have shared devices with non sudoers users. It works. It's not necessarily for everyone, e.g. not for powerusers who want to go fast very often, but it's definitely usable for most users still.
Linux root/regular-user model comes from an ancient time with multi-user architecture where you defended against one user taking over a big machine they didn't own.
But today on personal computers all the good stuff is inside regular users accounts, and there is nothing valuable to be gained by becoming root.
So the whole security model is broken, it protects the OS system files that nobody cares about, while allowing any piece of software complete access to valuable user files.
Well you of course want to sub-divide every application in user space either with gvisor or a hypervisor, like QubesOS.
If someone pwns your personal browser they should pop out into an environment where nothing exists but that browser, with no idea the work browser is in a sibling vm.
on Windows the UAC (GUI sudo equivalent) requires actual user input (keyboard, mouse) on a dialog presented in a secure way (can't be faked by malware)
UAC is only a sudo equivalent when running under a non-admin user account, at which point it's nearly as convenient to simply run admin commands from a command prompt running as a separate user, or a separate desktop session entirely.
I challenge anyone to name even one thing that requires sudo on a Linux desktop not better handled with systemd user units, Linux Capabilities, rootless docker, etc.
For root filesystems I am recently favoring EROFS which is read only, fast, and can run from ram.
On workstations I install almost all software to ~/.local as the home partition is writable. I also put all my systemd user units there, so I can run any binaries I compile as a system service to survive reboots as I like all without root.
The system root partition should contain a kernel, init system, and run any essential shared services unprivileged and fully/mostly stateless. Given that, I like to compile them all into a single UEFI uki image that contains efi shim, kernel, init all in a single binary that lives in the FAT32 UEFI partition.
The only reason to touch it is when you need to update your init system or kernel, which were always going to require a reboot anyway unless you get really creative with kexec. In an ideal situation the uki bundle is so generic that it is built deterministically in multiple locations and signed with a secure boot key. Then you can just straight up allow users to write to the boot partition, knowing any unsigned image that is not newer than the current one will be detected and also not allow access to the encrypted disk. The permission for that one update path can and should be external, and the result of a deterministic build matching a known hash, so you can prove it is not compromised. This could of course be automated by a distro with a UEFI wrapper or coreboot so users with no desire to customize their kernels do not have to think about it.
I am pursuing these ideas in stagex, first for secure enclaves and servers where we need it most, then for desktop. Until then Qubes is the least bad option.
stickynotememo: "How would you install packages (or update the kernel)?"
You: «You'd use sudo or su (of course) but I'm going to distract you from that with an advertisement for the work I'm doing on my personal project!» [0]
But, perhaps I misunderstood what you wrote. So... I'll ask stickynotememo's question in a different way:
How would a user of your system update the Systemd collection of software to apply a critical security update?
If the answer is something like "I'd rebuild the read-only root partition with the new code.", then I ask:
1) How does the data in that root partition get rebuilt? If it's on another computer, how does one control access to the root-partition-rebuild computer?
2) How does one instruct the user's computer to use that newly-rebuilt root partition? How does one control access to the system that permits one to load a new root partition and/or change which root partition to use?
3) How does a user recover when an update fails or is faulty in a way that your smoke tests didn't catch?
Please keep your answers concise.
[0] Personal projects are great, and I strongly encourage them. However, the way you've answered is what a greybeard would describe as "pulling a fast one". Pulling a fast one does not earn trust.
I am not convinced you processed what I wrote, but I will attempt to answer your questions anyway because they will aid me in writing docs later.
> 1) How does the data in that root partition get rebuilt? If it's on another computer, how does one control access to the root-partition-rebuild computer?
If they use an official one published by their distro, then it is likely sufficient that it is signed by a key in a multi-party-controlled remotely attestable secure enclave controlled by the distro team, which only does so in exchange for multiple signatures from independently controlled secure enclaves that produce deterministic artifacts. The key could be backed up and restored across enclave updates using shamir secret sharing so no single engineer gets the key but they can cooperate to provide it to an enclave.
Of course this scheme to avoid trust in any single human or machine in the linux distribution supply chain only works if you happen to have a deterministic full source bootstrapped linux distribution that has strong multi-party security controls (like stagex, my "personal project", protecting hundreds of billions of dollars in fintech infrastructure right now)
> 2) How does one instruct the user's computer to use that newly-rebuilt root partition? How does one control access to the system that permits one to load a new root partition and/or change which root partition to use?
If the high trust supply chain signed UKI builds are a thing, per question one, then life gets easy here.
On first install a user would be forced to enable secure boot enrolling the linux distro signing keys, and the installer would encrypt their hard drive to that secure boot state via TPM PCRs.
Now, even though the user-accessible portion of the OS is entirely unprivileged, the user can be trusted to download new signed UKI images and place them in an update search path. Now on reboot the update will be seen, verified newer, and could be kexeced to. If it boots successfully past the uki image, a hook will cause it to move the old image to a backup file and replace with the new one, then reboot properly. Secure boot sigs pass, image is newer than old image, TPM policies pass, and disk can be decrypted. All automated.
> 3) How does a user recover when an update fails or is faulty in a way that your smoke tests didn't catch?
If the kexec test fails to boot to the hook and drops a crashlog, then the original still-unmodified UKI image stays in place, will see the crashlog, and then boot normally and warn the user about the failed update and offer to submit an Issue.
None of this is novel, though knowledge of it seems sadly rare. All can be done right now with existing FOSS, and many embedded Linux devices and servers use patterns like these. Especially in high security environments like fintech. Just configuration, admittedly a lot of it, which is what I am packaging and simplifying right now in stagex so it can be an opinionated default.
> I am not convinced you processed what I wrote...
I did. There's at least one huge hole that the system -as described- seems to not account for:
> If they use an official [root partition] published by their distro, then it is likely sufficient that it is signed by a key in a multi-party-controlled ... enclave[.] Now, even though the user-accessible portion of the OS is entirely unprivileged, the user can be trusted to download new signed UKI images [from their upstream provider] ...
Distros often fail to preinstall all the software a user of a general-purpose computer needs. How does the user of this system add new system software to be used by every user of the system, rather than just the user who installed it? Suppose that the user wants to swap out the upstream-provided syslog daemon with rsyslog, or the user wants to install ghostscript for use by every user on the system... how is that done?
If the answer is something like "The user builds their own root image and signs it with keys that they manage, and then loads it into an update server that they control so their computer can automatically update to it.", then that's equivalent to using sudo with a ton of extra steps. If the answer is either "They use access control and elevation systems that means they're effectively root to augment the software load on the read-only '/'." or "Don't be daft, there's a single user on the system." well...
What mike_hearn said to you is also quite relevant:
> ...if all the apps that matter are installed to ~/.local then you're just removing the need to obtain root at all for most attacker priorities.
EDIT: There's another way a user can get new usable-by-all-users software on their root image: "Ask their upstream provider to add the software the user wants to the image and hope that they both accept the request and process it in a timely manner."... just like was done back in the days of glass teletypes, thin clients, and netbooted PCs. My recollection of (and participation in) a relevant slice of history might be why you think that I didn't "process" what you wrote. All that the system you describe seems to add is boot image signing... and I'm certain that ultra-paranoid sites have been doing that sort of thing for ages.
It's cool that you're experimenting, but if all the apps that matter are installed to ~/.local then you're just removing the need to obtain root at all for most attacker priorities.
A bit more than experimenting. I have designed several security hardened linux operating systems for major financial institutions.
There are many well established patterns for further segmenting user workloads, once far removed from real system root which is there is no good reason to expose. In my case each of those unprivileged apps runs in a dedicated virtual machine because I use QubesOS, though for many use cases gvisor or even containers (user namespaces) would get the job done with less overhead.
gvisor in particular helps you further reduce attack surface for root. It is possible to have your baremetal kernel not even have network support compiled in, and delegate all networking entirely to user-space inside gvisor.
But very few people are using their systems in ways that fit the Unix security model, which was designed for multi-user mainframes with only trustworthy software.
Yep, but pretty much every single piece of software you've installed on your system can read and write files to your home directory in a silent way without root, and that's where your most important files are on a desktop machine (API tokens, secrets, client projects, etc.).
I have my own opinionated Arch / niri set up and there's 1155 packages installed. That's 1155 opportunities for a package to be compromised. This is also why I try very hard to avoid the AUR and only use it as a last resort (I use 2 packages from it). It doesn't guarantee safety but the official Arch package repos do seem to have more checks and bounds vs the AUR.
Arch at least mandates author signed packages which is unfortunately rare these days, but keys do not need to be on smartcards, and code review is not enforced. You compromise the right arch maintainer and you could do some real damage.
Arch is second only to Guix in terms of supply chain security for desktop distributions, but both still have a threat model that cannot tolerate a single laptop compromise.
I do know some of the arch maintainers (e.g. dvzrv IIRC) are working on build infrastructure that would completely automate the build process and HSM signing to separate read-only images on build servers[0, 1, 2]. I haven't heard about updates to buildbtw in a while, but development seems still somewhat active and signstar is mentioned now and then at some conferences. It feels like it is not making any progress, but I don't pay any attention to the development, so it is likely just my perception of it just having been waiting on visible process to it and not seeing it.
I am aware of their work, and while this is better than the status quo, it does even come close to my threat model of "trust no single computer or machine" which is what I must support.
Funnily enough it wouldn't work for me as I use passwordless sudo thanks to PAM-U2F with a YubiKey Bio. I mean realistically speaking it probably would as I would just type it thinking "Hmmm weird" but still want to proceed forward ¯\_ (ツ)_/¯
Of course this style of attack would work on you. Attacker has the sudo wrapper that hooks your next yubikey tap to running any payload they want as root.
Your solution helps mitigate hardware keyloggers, which is great, but for malware in your home directory, it offers no advantages.
A 3 line change to my above code would do for your case. Obviously that is not production ready malware, it is just a minimum viable example for the most common target.
You type "sudo" and it runs an unprivileged sudo wrapper, and prepends your sudo command and runs real sudo. You tap, and your intended command runs as root alongside the attackers command.
You need a separate trusted OS to do privileged workflows from. Your setup would be effective if you were using an OS built for that kind of thing like QubesOS.
In my setup every app runs in a dedicated VM with a fake proxy smartcard, that routes to a real nitrokey in a hardware isolated and offline VM. That offline VM can be like "do you want to authorize a tap for aws.amazon.com" and I can be like "not today malware. I asked to login to doordash. nice try"
Desktop alternative to most uses of sudo: Polkit[1]. For a UAC style prompt, see AeroShell[2].
However, one still SHOULD NOT allow untrusted software arbitrary read/write access to their $HOME, even on a completely secure (and thus, imaginary) OS. No reason why every App X should have access to the files of every App Y.
>when it’s a very common setup to add regular user to the docker group.
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.
You mean the optional post install instructions, which is a separate page from the main install instructions, and contains a giant warning about the security implications?
Per my other comments, it does not really matter if you disable the sudo password or not. If you have a sudo binary at all you effectively are giving every user process root since malware can mask the sudo command and intercept the password so trivially.
The methods are described on the official docker website, not just random blogs or SO pages. There are caveats about security, of course, but it's not truly discouraged.
I think there are notes that warn you about the consequences. And they have been written with sys admin in mind which knows about user groups and security.
For a single user, opinionated, modern, developer focussed OS, this is completely and utterly on par. Using docker as a developer without this is just plain annoying.
This also seems like one of the more common things LLMs use to priv escalate themselves when not given root access, seems like a rather common misconfiguration.
Docker can be run rootless. It is so easy. No excuse for desktop distros to not do this by default. And that is why all major Linux distros are just as bad as Omarchy (Not recommending MacOS or Windows either as those are wildly worse)
Exactly! I was also surprised by this — that's a sensible default for many people.
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.
> Ubuntu has the exact same vulnerability out of the box, just with lxd instead.
No, it does not[1]. LXD:
- explicitly warns against this mode of vulnerability. Of course, there's no protection against people who blindly run commands copied from the internets, but the official documentation, at least, for as far back as I can recall, has had clear warning boxes against this, with explanations.
- does not have the track record of bad design that docker has had (IMO).
Yes, it does. None of this information changes the fact that, on a fresh install of Ubuntu Server 24+, the default user can privilege escalate to root using a few LXD commands.
Docker itself is such a massive security problem. Like it’ll punch through your firewall. Found out the hard way after a misconfigured redis was exposed to the web.
Somehow I doubt DHH and company would be OK sacrificing ""developer experience"" for security... There is still a non-trivial amount of docker-compose files and Docker incantations that don't work 1:1 with podman and podman-compose. Adjusting them would require Omarchy's users underatanding podman, and I doubt this will align with the opinionated nature of Omarchy..
As I said, podman requires effort and thought on the user's side, as the rootless part incurs complexity. I do not think that this aligns with the omakase mantra of omarchy. I do not think that DHH does not take security seriously. I think that Omarchy is not meant to sacrifice devex for security.
Rootless Podman (and rootless Docker for that matter) is not difficult to set up automatically. There is a little complexity involved, namely in configuring subuid and subgid mappings, but not much.
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 was not referring to the setup complexity. Setup is performed just once. I was referring to the runtime complexity that comes naturally from having to take into account non-root user permissions and lack thereof. These peculiarities are quite a low bar, but they are still a non-trivial hurdle in the way of devex.
I am a fedora/opensuse user and happily use podman with selinux.
Shopify forced him to be a vibe coder now. Omarchy is a vibe coding distribution.
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.
It's really disturbing that there's a group of these CEO/investor types that are openly white nationalists, and they're joining forces. I'll never touch any of their products, and I hope they continue to expose themselves on social media.
because the distro is all about convenience over security, while selling an aura of technical superiority. Which is the modus operandi that worked for the distro author in the past, when he sold VPS with a big markup, because he also gave a script that did "ssh vps -- curl somebashscript" to do basic webdev taks.
> 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.
I've used docker until recently just because it was what I was used to. It turned out I can basically just `apt install podman` and it'll just work. I might have stayed a bit behind the times with having podman slotted as a redhat thing.
Compose files work just fine. The gap with Docker has basically closed, and the few things you can't do or that behave differently are precisely the things Docker shouldn't be doing.
The Docker configuration issue was reported and changes were made quickly to address it. Sounds like this is a great example of the system working well.
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.
It's easy to disable rootful Docker support in an ISO, but much harder to fix the vulnerable installations. That is not the system working as intended.
And sadly, this stuff isn't bewildering at all. We saw it happen with LARBS, we saw it happen with Manjaro, then Archlabs, and now Omarchy too. All of them endangered themselves by shipping dotfiles that none of their users understood, and few of their developers would justify. When Manjaro's repos conflicted with AUR pkgbuilds, thousands of their users didn't understand that Manjaro had a special repo override for system packages that lags 2 weeks behind upstream. Omarchy tempts the same fate by stacking custom packaging channels and pacman scripts on-top of a system that gets advertised as "regular" Arch Linux.
Distro variety is always a good thing, but there has always been different levels of commitment to it. If I was putting together a Linux system for a kid or someone elderly, I'd just give them Fedora/GNOME instead of trying to get them into larping r/unixporn.
Personally, I wouldn't recommend any Linux distro other than Manjaro with XFCE, for a non-expert, because it just works and installing software is a breeze with Manjaro's graphical UI (pamac).
I've been running various Linux desktops since the late 90s and every single distro without exception has eaten itself from updates...except for Manjaro which I've been running exclusively now since 2018 without so much as a hiccup.
Two-week old packages is nothing. The most popular Linux distributions aren't even rolling distributions and they'll have you using packages that are years old.
This is a weird metaphor - why do you think people buy matcha at coffeeshops or use peptides? Those two things don't have anything obvious to do with each other, let alone with Omarchy.
Wow... this is really telling. This isn't some obscure whoopsie. The docker install page has a giant section explaining exactly this problem. Every Docker section on every distro wiki walks through this issue in detail. It 80% the reason Podman was created in the first place.
Ubuntu is good enough. I never got the point of tiling window managers, because the most important part of daily computing, browsing the web requires you to use the mouse. I’ve tried keyboard only browsers, none of them are as intuitive as just using a mouse and they can’t be, especially considering the prevalence of hyperlinks.
I guess while coding it is nice, but I can switch between the terminal and my editor in a single key in Ubuntu itself so I don’t see the point of this.
Valid, but I’m unsure if mouse use needs to be mutually exclusive with a tiling window manager, and would like to suggest that all tiling managers are not necessarily made equal.
Niri for example, tiles but additionally introduces an infinite horizontal space, where you can slide between different windows like they’re on a film strip. The slide into view works with a mouse, and you can easily setup mouse bindings to move and reset windows. I think it’s better than just a stock floating windows manager because it feels easier for me to navigate an infinitely wide left-right and up-down space as opposed to an infinitely deep space into and out of the screen.
Omarchy has me questioning liking Rails because it just… straight up sucks?
It comes preloaded with friggen ZOOM. I don’t think Windows bloat is that bad.
If it makes people happy it makes people happy I guess. These guys trying it would be even more amazed at Fedora Workstation (“you can press windows and it shows all your open windows? That’s so much better”)
i don't understand why DHH is shipping so much bloat in omarchy. The better solution would be to ask if user wants to install bloatware during installation.
Thats pretty good, then he should have made a toolkit for building and rolling your own badass distro and not a "opinionated" "omakase" system that claims to solve all of deskop linux while personally mocking a lot of people that actually have made real contributions as "clowns".
His tone is horrible. Because he implies untrue things while being 100% certain. He will paint entire communities as against omarchy when it’s just a couple left wing members with a stupid take. It doesn’t help the distribution is just … not that good.
dhh understands what a good user experience is. Installing in a couple minutes and getting right into it is an amazing start compared to most operating systems that take ages to setup.
Plus, many pre-installs (like Zoom) are web-apps that take no space (30 lines of text) and are easy to remove if you don't want them in the menu.
Have you… used any other Linux distributions at all? For longer than a month? Respectfully. The thing DHH killed was demoing Omarchy most stuff is in other distros out of the box. And like installing in a couple minutes is table stakes.
Yeah, GNOME was my previous preference, but I don't see myself going back now
Learning the hotkeys in Omarchy is a bit of a process, but there is a hotkey to show the hotkeys lol (super + K) - and once you get used to them, its super productive, at least to me.
Isn't Rails highly opinionated with a focus on being batteries-included? I'm not defending the choice to include Zoom but a batteries-included (for better or for worse) distro is exactly what I would expect from the creator of Rails.
A lot of the "pre-install bloat" are just web apps, including Zoom. Zoom is just an 8 line file so it appears in the menu and to point it to a 22 line bash script to launch the app.zoom.us website at the right address.
Easy to remove. Can even open your favourite AI assistant and ask it to remove it, since it comes with an Omarchy skill and knows how to change everything.
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.
If you are adding yourself to the docker group, you have presumably read the documentation and its warnings. Does an Omarchy user know the distro has made the decision on their behave?
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 am not disagreeing at all. Nor am I trying to claim this behavior is safe.
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.
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.
I don't use Omarchy, nor would I, but I think that "VERY, VERY" is a little hyperbolic, no? It's a simple `admonish-yellow` warning box that says something vague about root-level privileges and wants me to read more about what this actually means. I would wager that a large amount of people scroll past that with no second thought because it really doesn't come off as that bad. I know I configure most, if not all, of my systems this way. Many people probably don't actually understand the implications of what they are doing, and perhaps the Docker team should actually put a little bit more effort into scaring users off.
Perhaps Omarchy shouldn't have shipped this by default, but the whole point of the system is to be DHH's personal computer just the way he likes it (to include not 1, but 2 shortcuts to Twitter!) - all his products are that way and largely the reason why I don't ever think I could use one long term.
Once you have a box vibe coding has happened on I wouldn’t trust anything on it. Thats why I vibe code on a fully separate machine.
Im not an Omarchy user but we now live in a world where most of the actions (including ones the llm asks users to run as root) originate from somewhere other than the users brain.
There will be a reckoning in terms of how we think about trust and auth in coming years. It’s just a matter of increasing severity of incidents .
There are definitely a few security holes in Omarchy. I tried installing their win11 docker script and that just saves the username and password of the Windows VM as plain text in a config file.
I like playing around with Omarchy since there are a lot of interesting ideas put together in a semi cohesive 'OS', but would probably not use it for anything serious until it became a bit more mature.
you probably mean win11 vm script, that's not really a security hole, as the host running the vm you are basically root on windows anyway, unless you bothered to encrypt the drive inside the windows vm
My most controversial opinion by far in tech circles is that I still just use a standard Windows gaming PC as my home desktop. My current machine I just bought pre-built from Microcenter, complete with a 5090 and everything.
I can fire up a Linux terminal with WezTerm and WSL2 at any point. It's customized and beautiful and totally fine. I have Codex running in one right now. I can listen to Dolby Atmos music through Apple Music or fire up a game with zero compatibility issues and full RTX support. It's just versatile like nothing else. I pair it with a gigantic 48" LG OLED TV as my monitor.
The only thing that might tempt me away from this is a fully loaded Mac Studio with 512GB of unified memory. That would be a real capability gap from my current machine. But I've contemplated wiping Windows and installing Omarchy, and I just can't figure out really what I'd gain, but what I'd lose is quite clear.
Windows has also come a long way from a terminal perspective. Sure, the UI is a bit of a mess, but Powershell can do anything in the UI from the command line, and agents are very capable with PoSH. If you really care about ricing the UI, there's hundreds of utility apps to do almost anything you want.
Agents are also able to tweak and debug Windows errors, since the registry, group policy, event log, and other Windows internals have been largely unchanged for 25+ years and are well documented. All have old command line tools or modern Powershell to manage.
you have to understand that 90% of HN use macs and the only time they see windows is once every 5 years when a relative asks to setup a new or clean an infected one
there is currently no linux distribution where it's safe to run an application as is. they tend to have access to /home which is game over.
some people who actually care about security will create bubblewrap/bwrap profiles for applications and then run those profiles. an application isolated in this way will have a limited view of the system much less the ability to modify it. it usually takes the form of a custom /home for every app.
this still leaves the kernel exposed for an application to poke at and maybe escape with a 0day. some people run a VMM to further isolate the application, these days you can passthrough Wayland. if the application isn't graphical you should probably use gVisor instead.
Not an Omarchy user and use podman rather then docker. But is this not a docker issue rather then a Omarchy issue, docker should verify user permissions through the socket, it's quite bad that it does not no?
Sorta, but there is a reason that no other distro does this by default and that docker itself warns that doing this is effectively giving the user password-less sudo.
So this is a problem in Omarchy specifically since it does the dangerous thing silently and by default while everyone else tries to inform the user of the consequences.
I see, if it's common knowledge of people who use docker that rootful docker is root (though this does seem bad and they should just check the user perms at least) this sounds pretty terrible on Omarchy's part.
And the cycle continues. It’s funny seeing Omarchy (DHH) becoming popular when we had LARBS (Luke Smith) 8-10 years ago.
Something about a controversial personality pushing a window manager install script is really appealing to people I guess. At least it brings awareness that other desktop paradigms exist. Although after years of ‘optimizing’ my tiling window manager I just ended up back on KDE.
I hate to be defending Omarchy but I think for the modern desktop OS like Linux or Windows or Mac OS, "root" is not what it used to be.
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.
I would say that the traditional notion of Unix root and normal user accounts is outdated, no longer useful for how people use computers today. On my personal laptop, malicious code having access to my user files is as bad as having root access - I'm the only user of my machine - and I don't have any convenient way to create more granular security zones among software running as my own Unix user.
I can't fathom why it's so common to run docker as root instead of as an unprivileged user.
Docker has supported running rootless mode for years. I packaged the docker-rootless into Arch/AUR over 4 years ago, so it's been around and stable that long.
Sure, on a server dedicated to running docker containers, maybe it makes sense for the marginal improvements to network latency. But otherwise, rootless should always be the default.
There were many amazing distros before Omarchy and there will be many after. Use whatever you want, vibecoded or not. Don't tell people what to do. Make your own decisions.
Bigger question is does Linux need another distro at all?! I would say about as badly as Singapore needs a mall.
There's no doubting the brilliance of DHH and folks working on it. What if that went to into making a better UI, Desktop like Mac. After all Apple did that so well when they moved to Unix core.
I don't know much about Omarchy but this seems like a common way to use docker even on Ubuntu. As far as I know it's in the official guide. Why are so many people hating on the distro?
anecdotal and fwiw, Omarchy is the first distro that "stuck". I've been using it on my desktop for a year now. I use it for personal projects and light gaming via Steam. Personal MacBook is only used when I want to compute on the couch. Work computer is also a MacBook. But everything else, Omarchy desktop.
Previous attempts with Ubuntu and PopOS! never stuck.
OK... and? This doesn't matter for a desktop, because:
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?
Lol! He's gordon ramsay of tech, who's frequently contradictory himself. On Round 2 with lex, he said something like no one lost recently due to using digital Maps. Well, check this one - https://youtu.be/z5ElIor-oXk?si=XfcS1UtC2OWReVXr
He's bashing and insulting all engineers and then asking for their contributions and complaining that not many people are committing code in open source repos.
The point is that there are millions of people out there that are curious about Linux but are put off by anything command line. Distro like this, especially Quatro which has a big focus on agents, makes it more inviting and gives people an instant path to get help/have their problems solved without them having to search archaic error messages
The scenario of running any agent on the host raw seems far fetched for most users. I think everyone is running these things in at least a container, I know I never trusted running claude code or any agent for that matter, but I might be a little paranoid on that front.
Out of all the commentators here actually running Linux Desktop, I wonder how many have used Omarchy? To me its the best Linux desktop experience I've had without having to overly waste my time configuring things.
I just want to put this out there, smolmachines is a wonderful program to solve this, I use this mostly for stuff needing docker socket / docker in docker (example strix and agents). (I'm using podman on my host)
The guy who invented Ruby on Rails. He’s been pretty important in web dev and he’s an excellent engineer, although he’s a polarizing figure. He’s always been opinionated and never afraid to ruffle some feathers. More recently, he’s been posting some controversial right-wing stuff online that pissed off a lot of people.
Yes ok, but the moment you gain user access to my machine, I've already lost. The amount of damage you can do as root is about the same you can do as me.
Surprised by this. I only ever use podman (which by default, runs rootless) these days and haven’t felt the need for docker. Feels like reading about a CVE in Compiz.
This is the type of security and vulnerability testing that actually matters. In a sea of security researcher noise, thank you for contributing in a meaningful way.
Been using Linux on and off for 30+ years and I’ve always always had second thoughts about using anything outside the main 3-4 distros, and I mean forks, blends etc. let alone vibe coded distros, even *buntu feels like a stretch.
I really like DHH’s enthusiasm and what he’s trying to do but I will never touch that “distro”.
Debian/Devuan, Fedora/RHEL/Alma/Rocky, Arch/Artix, FreeBSD/OpenBS/NetBSD are all anyone will ever need.
You feel more adventurous? NixOS, Gentoo, Slackware, Void.
That’s it. No forks, no blends.
I keep Xebian and LMDE ISOs in my flash drive to show people but I don’t personally use even those.
People jumping all around these new distros that only seem to change a wallpaper without knowing the basics is a bad choice, like the first comment says, isn’t this the reason you wanted to move away from Windows in the first place?
Just take your time and enjoy learning, they are all so simple today compared to decades ago it’s crazy.
Ubuntu has the exact same vulnerability, except with lxd instead of docker, but for some reason, it's considered working as intended.
On a fresh install of Ubuntu Server, the first user created is part of the lxd group, can install lxd without root thanks to snap, and can immediately create a privileged container with the host's root filesystem mounted inside.
I genuinely put companies that invested in this on my blacklist. I don't care about the politics behind it. His whole persona is and was to be edgy and cruel so nothing will change here. But there are probably millions of oss projects that deserve the funding more.
To put out something that is opinionated, one needs to risk others being critical of their opinions. People who are always worried about having the “right” opinions will rarely risk stepping out and doing something different.
So all the safe boring stuff that gets released is just a defense mechanism, where people avoid going too far in and direction to avoid being accused of having bad taste. Ironically, this creates its own lack of taste. This lack of taste is usually just ignored as boring, rather than attacked, so it feels safer.
docker access == root, as long as you can use volume mounts to arbitrarily mount anything else on the machine to a container. If the user is in the `docker` group, he's effectively root because he can patch around system files.
I once used this to recover lost sudoer access to a machine (have tested this now by editing my sudoer file with a comment):
~ docker run -it --rm -v /etc/sudoers:/etc/sudoers ubuntu bash
# apt update && apt install -y vim
# -- edit /etc/sudoers
# wq!
~ exit
~ sudo cat /etc/sudoers - works, comment is present
It's disappointing to see the way the developers are pushing this pre-alpha quality work. I don't know (nor care) about the personalities attached, but the pitch is neat. The way it is being handled with almost daily reports of RCE/Escalation is jaw dropping though. They need to spend some of those bux on auditing and less on whatever vibe-based engineering they're doing.
For haters: ignore them and recommend your favourite.
For lovers: lobby the developers to raise their standards.
DHH is an influencer and people like to follow them. I know I did 20 years ago when his videos influenced me into saving for a MacBook. He basically meme'd web dev with rails on TextMate.
If you editing your system config with an LLM and tool calls, why wouldn’t you just use NixOS. At least if the agent broke your system, you can basically recreate it from scratch in under 30mins (some things still might be outside the system/home-manager config). But yeah, then you get diffs of what the agent changed in a nixos/home-manager change.
I see almost zero reason for anyone to use anything else for they’re base system at this point.
I mean, I saw this on twitter, and thought ok maybe its a nice exploit. But really? its the usual docker root thing?
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 am a little unsure why folks keep getting convinced one new distro or another is gonna come and finally solve the Linux desktop adoption problem?
The fundamental problem linux distros have is that they dont agree on a fundamental set of libraries, user experience, or have a stable abi. We've had minimal disros before, we've had maximal install-everything distros before, and we've had special purpose distros before (ie knoppix, mythbuntu, Kali). But the same adoption problem remains.
Afaict Google and Valve have managed to meaningfully move things forward with chromeos, android, and steam OS. Tools like flatpak and others also have made a difference.
But if you're really going the typical distro route, it confounds me what the point of going outside of the typical and common debian/redhat/arch systems are especially when its one guy. Hell, I still remember SprezzOS (Nick Black's Distro) and that thing had more real goals worth praising than anything I see from Omarchy.
I don't see a responsible disclosure timeline, putting doubt on the black/greyhat hacker, but am not surprised this was patched post-haste, unlike some less caring operations.
In any case, another reason to upgrade to Quattro! I just hope my 30€ Chromebook can handle it as well as it handled 3.
Other day i was hearing DHH talk on Lex's podcast on Omarchy and how he does not look at the code anymore. The guy built solid reputation with his prev contributions but now falling to AI slop.
I've already stated this on the last Omarchy thread, the way DHH is implementing it is highly irresponsible and insecure. Half of his "distro" are essentially shell scripts where it's extremely easy to create accidental security holes. Considering that probably half of his code would need something like setuid/execute bits set in order to avoid configuration spaghetti, I'd imagine that there are _hundreds_ of vulnerabilities in there. If you think about it logically, just the desktop environment (note that I have no idea if he coded his own or is using an existing one) needs access to input the graphics driver the netstack all of which require priviledges of some kind.
Sad that people just complain about what DHH is doing and how he doesn't know anything. Nobody is forcing anybody to use Omarchy at all. Also $10 million was raised by him for it, did anybody else here raise that for a distro? I'm tired of the constant complaining and criticizing. Nobody said you have to use it.
He clearly "suffers" from narcissistic personality disorder, trying to change him is a waste of time. Even if he was a normal person, I see no rational reason for him to change his behavior given how successful he is.
So what works for you: seeing him disappear from the Earth? He's not a human anymore? Have you ever spoken with him directly before? Or do you just read and write about people you've never had any real interaction with?
Some yes. I am not american, so i don't see anything particularly wrong with them. The main thing americans forget is that they are the invaders that replaced the local population and erased local culture.
This is hilarious. He isn't American and isn't talking about American in his racist rants. The people calling out his racism aren't focused on America or a majority American. His main blog post that gets called out for the blatant racism is titled "As I Remember London".
ot fyi: "omarchy" is fine as a creative spelling for omachi, but "omacon" / "omacom" has extremely low Levenshtein distance with the honorific form of the word for human female reproductive component in japanese
And the word "pine" is kinda close to "penis", what of it? Words in languages sometimes sound kinda like rude or sexual vocabulary, especially in a language like Japanese with a relatively small phoneme inventory.
> 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.
A few days ago someone found they were flowing USB descriptors straight into the shell.
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?
It's definitely not why *I* switched away from Windows
You didn't switch away from windows to get superior software?
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.
While I don't want to discuss the quality of any distro vs Windows, there is a big reason most of us use free software: because it is free. Whether for you it is because of free as in freedom or free as in beer specifically, quality may not have much to do with it.
Isn't Windows also basically free? Every laptop I buy has a Windows licence stuck to the bottom of it.
No and you missed the "freedom" part of the adage.
No, you've been charged for every one of those licenses.
which means you paid for it. just because it comes bundled doesn't mean always it's free. https://en.refund4freedom.org/
You can also just pirate it.
Windows is already free for ~everyone. Make less idiotic arguments.
In EU at least you can almost get free as in beer Windows, you can buy a fully legal 2nd hand (resold) Windows license for about $10, the price of a fancy beer.
> Also, the statement was valid because it will be true for most.
The statement seems more like a preconception than data.
My reasons to switch to Linux from Windows were very little about "security" and plenty more about freedom. Sure, it was very nice avoiding running an antivirus, but that was just the cherry on top.
I wanted the freedom to change and "rice" my desktop however I wanted, and the Compiz cube looked awesome. I found Windows condescending and restricting in that regard. Yes, my first reason was the aesthetics, kick me out of the nerds club. (That was also the reason I switched to Mac for 10 years).
My second reason was that I suspected I could learn so much more about computers using Linux full time. And I did.
I was also younger and used to associate Windows with soul-sucking corporate jobs and Linux with new ideas and experimentation. It was us-vs-them. Open Source vs Micro$oft and all that vibe.
I'm sure "superior software" is true for most, but that's a much wider goalpost than the people specifically worried about security/vulnerabilities. One of the biggest factors pushing people to Linux lately is the increasing number of ads and annoyances being crammed in to Windows. Security has been moderate for a long time.
Other than hype, what's the appeal here?
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.
Well the whole point is to have a good foundation and then make it actually yours, and the only necessary key binds are probably SUPER+K for the key bind cheatsheet and SUPER+SPACE for the menu.
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.
https://plugins.omarchy.org
https://omarchythemes.com
Hey, do you have any concerns about malware, in case of using the plugins or themes from these websites ? I was a bit skeptical, considering all the malwares that are being found in the package managers and plugins are pretty much the same thing but as extensions.
That is the appeal. It's an opinionated distro designed around keyboard navigation.
It is kind of nuts how little attention this more-than-controversial-enough aspect of it gets compared to anything else, to the point people don’t even know this about it.
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.
Can you say what you prefer? I'm always down for alternative UX flows and with hyprland being so user specific it's hard to see how people leverage it across the spectrum.
I just switched over to it from Ubuntu. So far the nice thing is that it gives you a fully decked out hyprland setup without any of the hassle and pretty good UX.
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.
Github is awash with people's dotfiles including fully featured DEs built on top of things like Hyprland and Noctalia, and they don't require you to use a mess of a distro to use them.
100% this, either use a DE like GNOME or Cosmic if you can't be bothered, or spend a little time looking at someone's dotfiles.
No need to use a whole distribution with 1000 other poor decisions made for you.
> No need to use a whole distribution with 1000 other poor decisions made for you.
I used Vim for a decade (and Linux for much of that time) and the constant tweaking and changing things drives you mad after a while. The more you invent it yourself the more it changes. This is why I prefer MacOS+VSCode these days, which comes with good defaults and simpler VIM-style bindings.
Omarchy sounds like those popular vim configs such as https://astronvim.com/, which I also tried using and also ended up heavily customizing myself. It provided some nice defaults as a baseline but was ultimately comes with too much hyper-customization (which has a lot to do with vim/neovim trying to act like other more modern editors).
There's a way to have 1000 poor decisions with your arch sure. I use Omarchy to avoid just that.
Yeah, I mean when I set up my last distro I just installed claude and told it what I wanted and in about 30 minutes it was up and running. No need to install random distros!
So, one config file? Why would you use a distribution for that?
I implore you to give CachyOS with Niri a try.
The nice thing about wayland is you can easily combine a compositor/window manager with a wayland desktop shell and get a lot of the stuff you used to have to fiddle with when using like i3 for free. For example, I use niri with the “dank material shell” desktop shell and get status bar, notifications, clock, suspend/resume, etc. all “out of the box.”
I got here because it was the first time I saw a tiling window manager on an Omarchy video. I was on windows my entire life, so when i saw it and how bad windows got, I decided to give it a try. A few months since I de-omarchyfied the system and went straight back to arch. And now still on it.
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.
you can pick the best things out of cachy without moving to it wholesale. Like their proton, maybe kernel or mesa
I for one hold out for them releasing an optimized XFCE variant - don't by any means dislike keyboard driven software but I like it as an extension of a regular functional UI experience not as a "argh the windows are stuck in xyz pattern until I re-remember xyz combo"-experience: the UI surface is not the speed limit in my optics, rather it is the apps I use or (increasingly due to local AI) the computational hardware limits of my machine.
There's definitely appeal in key-driven window managers in general. Projects like i3 and Niri are popular. But you can get that with any Linux distro (albeit not many have it set up that way by default). You don't generally choose a distro just for whatever DE/WM it happens to start with.
> 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.
Whoa! You have to _learn_ something to use it well? Yikes. Not for me.
conventions are a good things so you can minimise relearning.
Learn emacs once and use ratpoison, readline and rlwrap everywhere.
Being hyprland keybinding skilled removes a lot of the desktop interaction surface, it's a worthwhile investment. People who've used tiling window managers for a while will tell you that it gets natural at a point, then a whole class of friction that normal WMs cause just goes away.
On average, you can either have a discoverable GUI for noobs, or a configurable, keyboard driven system that's a giant pain to learn and configure.
Omarchy aims to find a middle ground between those two.
> either have a discoverable GUI for noobs, or a configurable, keyboard driven system
Absolutely wrong. Windows is both and it can be 100% keyboard driven.
Or at least, XP could.
Try editing key-values in Regedit using only the keyboard.
Set-ItemProperty -Path "HKCU:\Software\MyNewKey" -Name "Example" -Value "Blah" :)
You start regedit.
cursor up/down, page up/down, or F3 to search, hitting enter to follow directories, until you reach the key.
Hit enter on the key. The values will be displayed.
Hit tab until you are on the key you want to edit.
Hit enter. A popup with the value will appear.
Type the new value, hit enter.
A much more painless process than I anticipated, honestly, and it refreshingly uses the same conventions that used to be used everywhere in windows.
What I don't get is that VS Code has solved this perfectly via the command palette - you just bring up the prompt and start typing and it will find you the command you actually need without having to memorize anything.
We had people salivating over a spinning Compiz 3D cube 20 years ago, and some still don't understand the ricing factor.
There's a segment of people who are into customizing their desktop environment as a hobby and end in itself.
Personally I've never really been into it, and these days I have a broad and revolving set of machines I have to use, so this sort of thing is absolutely not worth the bother. I just install KDE Plasma and use the computer.
I recently customized my own Bazzite install to use hyprland plus other customizations, there's really not much different than what omarchy did. It's pretty much that with some pre installed apps. Anyone that gave them funding is an idiot IMO.
Then it's not for you, or you can't vision how 5 minutes of learning can save you hours of future time.
Having to know like 5 keybinds and no taskbar is absolutely the point and it's a beautiful concept of how to use your computer. And it works, if you are open to relearning just a bit.
This seems to be quite contrarian considering we had this on the front page of HN the other day: "Debian votes to allow "responsible use of generative AI".
I guess this LLM coding wasn't "Responsible" enough. hahaha
Let the AI bubble pop baby
Omarchy is all in on AI, if you look at the recent commits and the dev workflows they have set up you can easily tell no human is looking at all the stuff they are merging.
It's not the same thing as allowing some AI contributions under strict guidelines.
Even worse. They don't even have AI review them. I fed the commits that introduced the problem to a few frontier models and they saw several problems, including the aforementioned security problem. Even Mistral saw it. I did have to instruct all models to look for security problems, though, but still.
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.
On Lex Fridman recently DHH was enthusiastically bragging about how he was letting AI generate C++ that he intentionally wasn't even looking at, he was treating it as a pure black box and just submitting the output.
the unfortunate thing - is the money pumped into omarchy + the hype around it .... a lot of sheepish followers will just follow the hype.
the tech might gets fixed later.
you mean the fun and DX? lol
"Someone" didn't find that, AI found it. So it's not clear what your point is about vibe coding. Would humans have noticed this problem, especially given that it's not remotely exploitable? (you have to plug in a malicious USB device).
I think they mean that Omarchy is pretty much vibe-coded. Probably just an assumption.
It is, DHH doesn’t seem too shy about it
In a recent long interview with Lex Friedman, DHH explained that he's essentially doing pure agentic dev on Omarchy now.
https://www.youtube.com/watch?v=NYFGCESmikA
The fact comments like this get downvoted because what they say is inconvenient is one of the major signs AI has fundamentally broken HN.
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.
By the HN guidelines, it’s better to avoid discussing downvotes on HN
You are one of the people I am on about.
Here you are just wanting to appeal to the guidelines to shut down inconvenient but true statements, again.
HN has been fundamentally broken for a long time, there's nothing new or special about AI. It just joins a loooong list of topics where people abuse downvotes and flagging to punish people they disagree with.
Ironically, the right fix is to replace human moderation with AI. Every so often I think about creating an HN or old-Reddit style discussion website that gets rid of user driven moderation entirely in favour of "polite but free speech" rules, assessed by LLMs on the fly, along with ways for users to label comments with various adjectives for both their own filtering and training a RecNet. A bit like a mashup of Reddit, HN, Slashdot and new ideas.
Doing that from Europe is tricky due to the lack of the first amendment, but could be worth a try anyway. It could probably be sold to an American if local laws become too difficult.
Any interest in such a site?
Yes. An additional reason is that both X and Reddit are no longer viewable without logging in. This might attract readers, though perhaps not posters, who need to log in anyway. But your free speech rule might make the forum one-sided over time because users whose views are excluded elsewhere would concentrate there.
It’s that age old “start a docker container with the docker socket in the container and you are effectively root”. What are we talking about here? This is not new?
Apparently is for some people. Not sure why.
No. We're talking about USB device names being parsed as Lua due to some window title injection issue in Hyprland.
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.
> 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
I was just adding more context than your post included
Ah, the opinionated strikes again.
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.
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".
> 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.
Yes and?
Yes, and Arch is probably not the right distro for you if you think installing it is a "pain".
archinstall comes preinstalled on the official iso. It’s a normal install flow and takes 5 mins.
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.
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.
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
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).
Everyone knows that, but that was 20 years ago. Why do people still care?
He leveraged his past success as a web developer to get into online culture war punditry. Now he's a prominent race-baiting reactionary.
There's a sort of cult of personality around him at this point. His acolytes follow him for his nativist views, and then adopt his technology unthinkingly.
I don't know why my comment was downvoted above. This isn't a serious distribution and you shouldn't expect it to be. It's a vanity project of a niche alt right tech bro, and this is the level of rigor you should expect.
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).
> 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)
> The attacker could use `chattr -i .bashrc` with the same privileges before editing your bashrc.
No. Setting flags requires root privileges, sudo was implied. At least on my system.
> Also you will want to do the same to .profile (because of LD_PRELOAD etc).
Yeah, that's what I meant with additional files sourced by the shell. I knew about .profile, but I am not sure that's all of it. I think different distros may be set up differently in this regard. Also I am pretty sure, you can define function overwrites/aliases and execute code in any file getting sourced, it's not just LD_PRELOAD attacks.
>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?
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.
Take a look at docker-socket-proxy as a somewhat of a counter to this issue:
https://github.com/Tecnativa/docker-socket-proxy
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.
Vibe docs?
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?”
> 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?
Official docs cover those:
https://docs.docker.com/engine/network/firewall-iptables/
https://docs.docker.com/engine/install/linux-postinstall/
Are there other things to be wary of, though? It's easy to find information about things one already knows about.
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.
> rookie mistake
Unfortunately, it's hard to classify something as a "rookie mistake" when the developers behind the most revolutionary enterprise tech in the world have accepted it as "by design" & just put a hard-to-find disclaimer about it on one single page of their dense docs.
It certainly does help quell imposters syndrome whenever it creeps up on my though.
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.
> But, this “vulnerability” is the thing everybody knows about docker since forever
OP’s point exactly - it seemed somehow in their vibecoding workflow, they forgot to even do a human architectural sniff test for the stuff everyone knows. It reflects very negatively on them.
Vibecoded fixes are quicker
On the flipside, once you use an OS that is totally open to agentic stuff, there's no going back really.
I can open Pi and ask it to fix some window tiling issue, help me install shortcuts, help me figure out how to install flatpak vs appimage, etc. the list is endless. I cannot see myself going back to a legacy OS unless I'm forced to by my job for compliance reasons.
> etc. the list is endless.
Why is the list endless? I don’t even remember the last time I check or change any on my mac settings. And my unix things haven’t been touched in months. My debian server is basically frozen at this point.
I encourage you to think more outside of the box and dream. There is much more you are able to do now, that would have been impossible 2 years ago! :D
https://x.com/SergioTapiaDev/status/2094187967900266573
That’s like one of two lines of i3status. Awesome if you need something like this one and built it. But don’t pretend that there aren‘t myriad solutions out there that have solved a lot of possible use cases.
I know this isn't your point, but world clock widgets have been a think since Windows Vista at least.
I can't tell if this is performance art or not.
"Think outside the box and dream!"
"Here's a world clock widget."
>If you use Omarchy, the most important takeaway is simple: update to 4.0.1.
More like, don't use Omarchy, or vibecoded Operating Systems.
Running a descriptor into a shell command is laughably sloppish.
> It's why you switched away from Windows in the first place, remember?
Really good reminder I gotta say
I think people shouldn't just jump to distros which are getting heavily hyped in media/Youtube, cachyOS had similar wave, and now Omarchy does.
(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
[1] - https://wiki.archlinux.org/title/Archinstall
Just use Fedora. It just werks (most times).
I like the very non-windows very non-mac ui of omarchy.
UI is desktop environment and (usually) ports to large-use distros cleanly.
- 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 run Niri and Dank Material Sell on Fedora. It’s perfect, and better than Omarchy from what I’ve seen. I much prefer scrolling window managers to tilers.
Yup. I've been on zirconium (https://github.com/zirconium-dev/zirconium) for a while, and it's great. Fedora atomic/bootc under the hood with Niri+DMS. Basically bombproof.
Fedora (or debian, or archlinux or whatever distro you choose) doesn't force you into an UI. All of them have minimal, server and/or "flavored" versions and you can always uninstall and install whatever you want.
So you need a new theme, and not a new OS :-)
is there a fedora 44 ws with non free package built in ?
You still have to use rpmfusion, which isn’t a huge deal. It’s maybe 5 min one time and then you are set.
Or you could use one of the Universal Blue spins. Bluefin and Aurora have non-free stuff built in and you can install pretty much any package from anywhere.
oh thanks a ton
Fedora is an arse to use. most of the distros for non free software are targeted at stable RHEL, so are miles out of date.
You only get 6 months of updates, at which point everything break subtly, or not if you use nvidia.
ubuntu with a custom GUI is the way forward, at least compared to fedora.
Counterpoint: I've had very few (and always minor) problems upgrading between major Fedora releases over the years with no more effort than following the well-documented steps to do so, including both traditional and atomic variants, the latter with a wide variety of layered packages as specifically not recommended due to potential problems when upgrading.
And on the server side of things, I ran a Fedora CoreOS VM with a Pihole container that silently and successfully auto-updated both the OS and the service container for years with no intervention on my part.
I had to support fedora on desktop and laptop for a large company.
Worse, it wasn't my job to support those machines, its just my department needed cuda and I was the slowest person to run away when they called for help.
I think this is more about the UI, rather than the install. I haven't tried it myself though.
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).
Ah yes, the solution to software with massive security holes is for everyone to vibe code their own software with massive security holes.
But in all seriousness, I am running omarchy now, and I will almost definitely be switching to arch at some point in the future.
Even if you introduce bugs in your UI (which I think is not very likely if you have a basic understanding of your system), the chance that someone would exploit software that literally only runs on your own machine seems extremely unlikely to me.
I've been using arch for over 10 years btw.
Isn't the other half of AI that we can afford to look for exploits in one-off software?
The old human nature tendency of "Just ship it!" and the desire to move on to the next shiny thing on our wishlist doesn't go away with AI. If it anything, it makes it worse.
I am not sure how someone would run an LLM on my computer to look for exploits as the source code is only available on my machine?
Yeah, I could literally open up a port on my computer which executes everything sent to it. As a bespoke app, it's pretty unlikely that it would ever be exploited even though it's ridiculously dangerous.
To be at risk, you'd first need to publish your application. The attacker would separately have to figure out how to identify and access your computer for attack.
Add that annoying theo guy to that list. Cant stand these people, they confidently push out videos like they're experts, a week later it turns out whatever they were talking about was total crap and they've already abandoned it - case in point OpenClaw. Look at the mess of videos those named above put out about it, not a single one uses it anymore.
There is only so much a human can master in his lifetime. And if you choose to master the art of video production, then you are probably not spending that much time on mastering the thing you yap about on camera…
which is why you have to hire people who master the art of yap whatever on camera, so the video production guy can have something to work on.
or did you think onlyfans?
> if you choose to master the art of video production, then you are probably not spending that much time on mastering the thing
What?
Its perfectly possible to master two things. Video production isnt _that_ hard. Especially as lighting, shooting adding graphics and editing film is much much easier than 10 years ago.
I was watching one guy explaining the xv6 code and it was pretty much one shot with a single camera pointing at the listing on paper. Not sure if you need professional video if you want to really expound on something.
Counter example: https://en.wikipedia.org/wiki/Hugh_Laurie
Musician, singer, novelist, comedian, actor, producer
as primarily influencers they make money from your attention, not from promoting or making good software.
Not a single mention of Pirate Software yet?
Am I missing something? What does pirating software has to do with that thread?
You are not missing anything for not knowing but Pirate Software in this context is another youtuber/influencer.
Sadly, true. I know a person who gets AI news from that YouTuber and quotes him like he’s a household name and pays him for some repackaged chat models. It’s tedious and hard to talk to them about basic/remedial aspects because their education from YouTube is half-heard and superficial. I’m trying to get him to invest the time in hands-on experience and then we can talk about that. When you’re deep into these channels, you’re not gaining experience and you can’t easily start until you pull away.
> they confidently push out videos like they're experts, a week later it turns out whatever they were talking about was total crap
100%! When the US attacked Iran, they became experts on wars; when Iran closed the strait, they turned experts on foreign policy, diplomacy, and negotiation; they were doctors during COVID; now they are SME in flooding and disaster control after the Nepal incident.
It’s sad, but a lot of software folks have decided to become influencers and not pursue expertise. I remember before you’d mostly be reading boring looking blogs to follow experts in the industry. It seems like the mindshare has moved to flashy videos by people that aren’t experts, but are great at communication. Similar to how if you want to watch some diy video on YouTube, you’ll get much better information from a poorly produced snd edited video from someone that knows what they’re talking about vs a well produced and edited video from someone that has no idea what they’re talking about.
I don't think I've ever actually seen a theo video, but I stumbled across this and think I've seen all I need to know. 3:45 even references your criticism.
Average Theo Video: https://www.youtube.com/watch?v=h1p9zdUtUdo
Omarchy imo is best for agent maxxing Mac power users who aren't locked into Apples proprietary apps like Final Cut, audio production software or Adobe and Affinity, so maybe not so great for designers and photographers as the main system.
Omarchy seems to be pentested by a bunch of angry haters. Who's pentesting your arch install? :P
Basic docker users are the same as angry haters I guess.
That's not what I claimed or said, do read my posts please and project less :)
No harm, no foul izacus. I am laughing inside because I'm included in the "angry" group by default (I hate all Linux distros, less than Windows or MacOS) and I'm often a basic docker user but got over major DE customization like Omarchy when I needed to get thing done at a higher rate (back then the coolness was crunchbang).
I had just enough issues with archinstall the last time I tried it that I went back to EndeavourOS which essentially gets you a GUI installer and some pre-installed utilities on the stock Arch install. The only significant change I'm aware of is that they use dracut instead of mkinitcpio.
Everything hyped is usually a counter quality signal
I think you are probably missing critical point that for someone omarchy is not about “bare arch”
UI is crucial. If people want something easy to use out of the box without spending days to configuring it
I think I get your point as omarchy represents a different kind of UI, but if it was just about getting a rock solid stable working environment, Fedora or Ubuntu with either Gnome and KDE work perfectly fine. I don't even use a third party terminal (just konsole). Keyboard driven terminal workflows works fine on KDE for me.
It's fine if they want to jump on fad distros. After all, Linux is a hobby OS, it's not for serious work.
yea... Not like most of the worlds compute runs on linux.
The problem is not the hype, the problem is that it's a vibe coded distro. AI lowers the bar substantially in terms of needed competence and diligence to create something like this. Of course bugs and issues are present in human created software as well, but now that everyone can vibe code a distro the chances of low quality software are much greater.
i think cachyos actually does interesting things, but i still would never recommend an arch based distro to anyone
Linux isn't like macOS, it doesn't have any kind of proper desktop sandboxing architecture that really works. So this is kind of security theatre. If you run a malicious program it can do stuff like tamper with your PATH or exploit local vulns in apps to get to the point where it can control anything that matters (which root generally doesn't). For instance it can just drop a custom shell into ~/.bin/.hidden-shell and reconfigure the terminal emulator to run it.
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.
> it doesn't have any kind of proper desktop sandboxing architecture that really works.
Bubblewrap works.
and Firejail
and sydbox
Bubblewrap is a less powerful version of sandbox-exec, but the macOS architecture is much larger than just that. In effect macOS runs everything under bubblewrap, in such a way that users don't notice but apps are meaningfully sandboxed and root exploits barely matter.
> Unfortunately implementing an Apple style architecture on Linux would be very difficult.
On desktop Linux as we know it, yes, but Android manages it alright, mostly via SELinux+seccomp.
Android is basically a different OS that happens to reuse parts of the Linux kernel.
Yes, it reuses all the security features.
Doesn't each app run as it's own user? The OG of security features.
It respins UNIX security in favour of a mix of SELinux and a (mis-)use of UNIX user/group identities to contain apps instead of users. Linux distros sort of do that too but only for system services, whereas Android does it for user visible apps.
> Linux isn't like macOS, it doesn't have any kind of proper desktop sandboxing architecture that really works.
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.
There can be exploits in any security system but the architecture is sound. There's no equivalent of TCC on Linux (I mean one that really sticks), and no easy way to create one.
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).
Mac users always like to defend some of the things Apple legitimately got right over most Linux distros, but always ignore that supply chain security and standard package management security on Apple (Homebrew) is akin to giving a bunch of internet randos root access to your machine with no oversight, vetting, or code review of any kind. At least most Linux distros do basic package signing.
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.
Homebrew isn't standard package management on macOS. It's an aftermarket mod that Apple didn't have any design input to at all, and which largely imports the laissez-faire Linux approach to packaging to an OS that has a totally different design for native apps.
> 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.
It should be the other way around. I'd be extremely careful before allowing anyone to manage prod from anything other than a Mac. Apple has an OS design that can be solve many serious supply chain and credential stealing attacks. SREs don't maximally exploit it today, and Apple only focuses on consumer use cases so they aren't going to use it to solve server management problems. I think there's a business opportunity in fixing that. But Apple has put in place all the infrastructure you need, whereas the Linux community simply hasn't.
> It's an aftermarket mod
Unfortunately one I have never seen a MacOS production engineering guide that does not say "install brew" as like step one, exactly because Apple failed to provide a software suite sufficient to meet developer needs on par with that of major linux distributions. Macports is at least maintained by current/former apple employees and signs their packages, but in practice no one knows macports exists.
> I'd be extremely careful before allowing anyone to manage prod from anything other than a Mac.
I would never even consider letting anyone near production Linux servers if they are not comfortable enough to maintain and secure Linux on the computer in front of them.
> I think there's a business opportunity in fixing that.
Me too! I am in the current YC batch for exactly that reason with https://caution.co , built with https://stagex.tools.
Ah, neat. I did something like Caution a few years ago but for Intel SGX, called Conclave. It made it much easier to deploy apps to enclaves, get remote attestations and communicate with them securely.
Unfortunately it's a difficult space to work in. SGX tries to remove the kernel and hardware from the TCB but there are a lot of obscure attacks to do with tampering with the enclave's sense of time. It's not an SGX problem, it's inherent to enclaves not having enough trusted hardware like signed clocks, tamper-resistant counters and so on.
Also the programming model has to be adapted but most customers just want a button to click for a box to tick, then they can say they're protected. Very few want to change their app architecture to be more secure.
Homebrew is far from ideal, indeed, but MacOS was never really marketed as an OS for people to manage remote server clusters. If you stick within their designed ecosystem and only do software dev for native Apple desktop/mobile apps using XCode, then you don't need homebrew.
> It's not an SGX problem, it's inherent to enclaves not having enough trusted hardware like signed clocks, tamper-resistant counters and so on.
Those things all exist now in several forms. You were just too early! (I know the feeling from past companies). SGX is a giant pile of design flaws I abandoned pretty early, but _TDX_ is what SGX should have been, and AMD sev-snp is wildly ahead allowing hardware memory encryption between different nested protection rings.
Back before these nice things, I co-designed custom hardware security modules, which was my "do things that dont scale" period.
> Also the programming model has to be adapted but most customers just want a button to click for a box to tick, then they can say they're protected. Very few want to change their app architecture to be more secure.
None of that is required anymore. With our design it is no harder than using Heroku. Bring the code you already wrote. Enclaves run hardened Linux kernels. If it can run in a container it can run on Caution.
> Homebrew is far from ideal, indeed, but MacOS was never really marketed as an OS for people to manage remote server clusters.
And if people on macs stuck to media work, we would have no issues. My rage comes from most sysadmins in silicon valley using homebrew/macos to ssh to production machines full of user data, and sometimes with billions of dollars in value attached. That is when I go into BOFH mode and start revoking access credentials.
> 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.
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.
The right right question would be: why aren't we enforcing a document to be self-contained? Why are documents agents? Why can any document access anything or indeed, do anything? That's not a document, that's a program!
Documents containing scripts are genuinely useful, as are, say, Python programs.
A python program isn't a word document
People write real software using Microsoft Office's scripting features. Sure, it's not "cool" the way that Python is cool, but it works.
And neither Microsoft nor Python has a credible security model.
They shouldn't be able to do that, because it's a huge security hole.
I need to write a proper introduction to macOS security because this thread has lots of incorrect assumptions about it!
macOS doesn't determine once whether Word can read all your documents. That's the sort of policy that applies to non-native Mac apps. Word is a native Mac app built according to Apple's design specs. Like the rest of the Office suite it opts into the stronger "app sandbox" feature macOS offers. That means:
1. It can only read files that the user granted specific access to by opening them with the system file picker. This grant is persistent across app restarts, upgrades and file moves, but is fine grained.
2. Its own files are protected against tampering from other apps. That means not just the app's binaries (which are protected in all cases regardless of app opt in), but also its own data files stored in $HOME too, like download caches. Obviously its address space is fully protected from debugging APIs too.
So if Word is compromised by a macro virus or buffer overflow, or whatever, that code is very constrained. It can't steal your SSH keys. It can't tamper with your ~/.bashrc. It can't tamper with your operating system, or escalate to root, or phish any credentials from you. Despite that, Word has all the functionality users expect.
Additionally, if you download and run malware, that malware can't edit the configuration of Word to inject macros, and if you store files in Word's protected area they can't even read those files.
MacOS only falls back to coarse grained permissions for looking at certain sub-folders of $HOME when apps bypass the native Cocoa APIs, e.g. by using open() and readdir() directly. This usually means some dev tool or script that was written with Linux in mind.
All this is possible because the kernel has very sophisticated support for app identity and security. It's exactly what you're asking for, and what Linux has failed to provide. You can open a file in Word thus granting Word access to it without even realizing you're doing it, then upgrade or downgrade Word without it losing access, move those files around, move Word around, download a beta version from some internal MS server and have two versions installed at once, etc. It's all possible because of sophisticated kernel level support working in close tandem with a lot of userspace infrastructure which is missing on Linux.
Re: entitlements. Apple's system allows entitlements to be self-declared, or granted by Apple, or both, or granted by non-Apple authorities if the OS is so configured (this latter fact is documented but obscure). MDM, app stores and anti-malware systems exploit entitlements aggressively to understand what apps can do. Their system allows a pretty complex ecosystem to develop where users can delegate trust as much or as little as they like.
> 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.
How is that different from creating a new user to run that script? This has been the standard practice on Linux for decades, and it is how I run tools like Codex and Claude on my machine. I wouldn't allow AI tools access to files, mount points, etc, owned by my main user.
This works best for terminal apps; for GUI apps such as Steam and games where running a separate graphical session isn't practical, you can use bubblewrap.
The obvious difference is that you have to create that other user (as opposed to denying the ~/Documents request). Also when you curl|bash you normally want to install under current user -- not something you're supposed to do on Linux.
I don't actually believe that macOS protects me here, as I granted this permission to the terminal five years ago...
I mean SElinux plus cgroups is probably good enough. Although as soon as it talks to the desktop environment all bets are off.
In my personal opinion, SELinux is a rather poor design, and I find that it actively gets in the way of trying to do security well.
Its opposite. Windows and MacOS lacks proper sandboxing. While openbsd has pinsyscalls and linux has seccomp-bpf. Windows and MacOS only have filesystem and worse version of user namespace sandboxes, anything else and you need to write a kernel extension or rely on a hypervisor.
> Unfortunately implementing an Apple style architecture on Linux would be very difficult.
The apple apps kind of thing already exists and its called flatpak.
Windows has virtualisation based sandboxing and NT has object-level security (albeit not often used correctly and granularly) and macOS has (among other things) SIP and a subsystem called sandbox that does exactly what it says: it sandboxes. It can sandbox in comparable namespace terms (like cgroups v1 or v2, but more in translocation style execution since it's a MAC framework) yet it also does it a much more fine-grained level depending on what you need. It is used by launchd and applications by default, some entitlements require it so if you want to do some broad kind of elevated application, you also have to have a specific sandbox profile. It's also been around for 16 years, and comes with a ton of examples if you wanted to use it yourself to constrain some process. Yes, it can do filesystem (would be pointless without it), but also does ipc, io, network, memory, fcntl, sysctl, mach ports, sys calls, processes, ui, sockets, messaging, events and all of that including context-aware filtering and compound matching for all of them. And if that's not enough there is also ESF and NEF, the latter only working on networking. You can compare those two to eBFP LSM and XDP. If you want all of this on linux, you'll need to add a lot of custom eBPF and LSM as well as always run in a hypervisor for guaranteed IOMMU usage, but you can't use bare KVM for that either, so you'll either need to never touch the privileged kernel (not even give it a console) or you need to run Xen and use XSM.
Flatpak is just a cheap container copy. Can't do anything beyond what cgroups and things like apparmor and selinux can do, and uses a runtime to do soft higher-level policy functions that translate down to the same primitives. If anything, it's a great bundler, but doesn't do anything new policy-wise.
So, can you get the macOS-level capabilities (both low-level and higher abstractions)? On Linux, yes, but they don't exist yet. On Windows: technically possible, but since that would break most GUI workflow it's not likely that anyone is going to bother, and you're going to have a hard time recompiling windows yourself to make that happen.
Hello, can you tell me if I can filter syscalls made from a memory address in macos without virtualizing the process, or requiring special entitlements and root? I currently have a project where sandboxing is important and i need to prevent all syscalls from a region. This is very simple in linux, and on openbsd i dont have to do anything because openbsd by default does not allow untrusted callsites from making syscalls (and the region in this case is not loaded by openbsd's dynamic loader).
On macos i currently virtualize the process itself, but this has virtualization overhead and some emulation overhead because macos does not let you map all the host process pages to a guest.
I don't think so, the XNU and macOS LS architecture doesn't assume you're going to do policies based on the internal memory topology of a process. It's usually done with multiple processes and having one be very constrained doing only some very specific calls and the other not being able to do any calls at all.
You can probably get by with mprotect or mach internals, but if you're developing at that level you've probably already either implemented or dismissed that.
It's a bit of a different architecture with PAC/MIE/APRR (and to a degree AMFI) being used to prevent abuse that would require syscall filtering in the first place. While I personally don't think that's airtight, it does appear to work out well for their ecosystem.
Edit: come to think of it, region-based call filtering is never really going to be enough on its own, if you don't combine it with other techniques it's basically a rop gadget fest. Probably also why SBX went for intent rather than trying to do it based on location/origin.
Windows has a brokered sandbox architecture too these days, but it's very new and nobody uses it.
macOS absolutely has sandboxing, what are you talking about? But the reality is that you need custom sandboxing tools less when you don't have basic problems like "anything that runs ever can read my ~/.ssh directory without problem" or "you can hijack my password by interposing sudo and thus do anything". This does not matter because macOS will see a program signed by Corp XYZ is trying to read data not owned by that cryptographic signature, and it can't escape the code signature check, and it will flag it. A program cannot simply read your password from stdin and elevate privileges silently, because granting new privileges requires communicating with a higher privilege program so it can delegate to you, and that program has a non spoofable prompt. And so on.
You can use Linux's sandboxing functionality to make a pretty hardened server. If you take in mind the physical deployment and go the extra mile, it can be very secure. The Linux desktop is not and will never be secure in its current form from things like extremely basic local malware. You would have to redesign much of the desktop stack from the init system downward so you could easily do things signature-based identity, proper per-identity secure storage and key management, securitizing elevation of privileges, getting rid of setuid, etc.
They purposefully used a weasel word - "proper" - to shift the argument to being about their opinion on what a proper sandboxing system is.
This isn't the case at all. Please learn about Apple's security architecture before making sweeping claims like this, it is very deep and has nothing to do with user namespace sandboxes. Windows also has a sandboxing architecture, it's just not as good as Apple's.
FlatPak's security architecture is an attempt to sort of head in the same direction, but they are a decade+ behind and will probably never get there.
> Linux isn't like macOS, it doesn't have any kind of proper desktop sandboxing architecture that really works.
As a QubesOS user, I beg to differ. Just because most Linux distros are negligent with sandboxing does not mean all of them are.
Funny because there is a 101 level Qubes RCE on front page right now.
Eh. That happens sometimes, but its design and track record is really good.
Sigh. Qubes had some great security design and implemented it the only way time/funds would allow: by cobbling together a lot of unfortunately very complex and broken things built for a different security model decades ago.
Qubes is the least bad option for laptops (until Stagex Work ships which I am designing) but there is no reasonable server OS.
I am ripping off the best ideas from xen/Qubes and starting over with: https://distrust.co/blog/enclaveos.html
what are you on about? The fact Qubes has to exist proves Linux is insecure. QubesOS is not a Linux distro. It just happens to ship dom0 as a Fedora VM. But it doesn't just support Linux, it also supports Windows and BSDs. None of Qubes security guarantees come from the Linux kernel.
The issue is not that Linux lacks a central authority that holds some encryption keys and controls what software you can run. The issue is that you should not run any software from a source that can't be trusted. When we used to run only software from community distros or that we compile ourselves, launching a malicious program was a non issue.
To be fair it is easy for malware to escalate to root on any major linux distro because sudo is completely security theater.
Malware just need to put this in ~/.bashrc and wait:
function sudo () {
What? Why is sudo security theater?
Because it is trivial for unprivileged malware to phish the password and escalate to root. No production system should ever ship with sudo.
You do realize you can do the exact same thing on macOS? Just alias sudo to whatever you want. BSD I assume you can do the same with doas.
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.
No popular Linux desktop, I would grant you. I use QubesOS and my own distro, stagex.
TIL. Thanks for your input into how sudo might not be super secure on systems already dribbling with malware.
You basically don’t use sudo on macOS though. Maybe once in a blue moon
You're making a big assumption about how other people use their computers. If you're running mostly desktop applications on Linux, you wouldn't use sudo much either. And if anything, I use sudoish-to-actual-rootlike on Windows more than on Linux, because more things are gated behind elevated privileges (some papered over by default UAC settings, but only when manipulated through built-in GUI tools) and there's nothing as simple as Distrobox and rootless Podman to set up isolated non-root environments.
Any user process can append anything they want to your shell rc (.bashrc, .zshrc). In this case, they added a bash function for a fake sudo prompt. It then uses the password the user entered to run a malicious payload as root.
If you're running a malicious user process with write (or read) access to your files, you are arguably already compromised.
The freaking point is that basically anything worth running will have that amount of access, even Flatpaks. And you don't freaking know what's malicious before hand.
I think that depends on your point of view. I wouldn't run a program on my computer unless I were sure that it's not malicious. And if you mean that some program I already trust could be exploited, that's true even for the Linux kernel or any sandbox / security solution you would come up with. I'm not denying that there's always a risk, but there's nothing good in running arbitrary code that you can't trust.
Exactly the point. You are already fully compromised, sudo adds no security.
It’s not, but the grandparent does point out 1 major flaw with sudo being a typically command that goes through normal path discovery. It makes it easier to escalate from a compromised user account to a compromised root account, since the end user is likely to type the root password into a command that can be shadowed in their user space.
You need root in order to overwrite sudo in the first place I think, but yes password replay attacks are real. 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. You don't even need a password at that point. Unfortunately haven't figured out how to make this work over SSH.
Look at the excerpt. They're not overwriting the sudo binary. The attack vector is real for malware running on a administrator user session which can be escalated to root via sudo.
It's a niche, but it's real. Esp. if you're targeting npm installed user scripts or similar
No, the above attack writes that function into bashrc, meaning the next time the user runs sudo themselves, you harvest their password.
> You need root in order to overwrite sudo in the first place I think
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.
You do not need root to run that shell function, nor to get it loaded into a shell's environment.
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.
Indeed, and most flatpaks have access to the home directory so are also able to do this even though they're """sandboxed"""
I don't think flatpak allows access to hidden files so even those with access $HOME cannot do this.
Flatpak uses Portals to let the user grant access to different files/directories, apparently they don't have access by default: https://docs.flatpak.org/en/latest/sandbox-permissions.html
I was also unable to find any Flatpak that has access to the home directory when installed, you may well be right but I couldn't find any. I used Flatseal to verify the permissions: https://flathub.org/en/apps/com.github.tchx84.Flatseal
I'm also of the opinion that we generally shouldn't use software that we don't absolutely trust. That has kept my .bashrc (and other files) safe so far.
To be fair it's possible the situation has changed since I last checked. But at least it used to be this way (https://flatkill.org/2020/). I'm glad the situation has improved in terms of security, but I'm still not a big fan of the flatpak design as a whole.
Wow. This never crossed my mind but of course that's so simple. There really needs to be a better solution.
There is. Simply do not install sudo and do not allow access to root at runtime. I am serious. There is absolutely nothing you cannot run unprivileged these days. Can even run sshd from a systemd user unit in your home folder, and even assign port 22 to it if needed with Linux Capabilities.
How do you update the kernel?
Idk why we need to use sudo to update kernel. In macos, we don't need sudo access?
You do need some root process to be able to write the updated kernel image to a root owned directory. On macos that is presumably their update daemon, while on something like ParticleOS[0] IIRC it is the systemd-sysupdated daemon, though I don't know if you can initiate the update as an unprivileged user or if its done on a timer or only root initiated (sysupdate has had a lot of changes not too long ago that reworked it extensively. It use to be something only root invoked transiently with a possible timer to "update all", but now it has a full on daemon).
Basically the reason we "need sudo access" (or anything to elevate privs to root) is because how the system is architected and changing that is mostly only possible on new distros which can decide to change the architecture.
[0]: https://github.com/systemd/particleos
See my reply here: https://news.ycombinator.com/item?id=49504775
Just don't be in the sudo group.
So the solution is to make your computer basically unusable. I guess that's one way to secure things.
On a modern Linux system you do not need sudo to compile software, install it, or even run it as an unprivileged system service in a User Namespace bound to port 22 (if you give your user the correct Linux Capabilities).
The only thing you cannot do as an unprivileged user is update kernels, but that requires a reboot anyway and the risk of letting an unprivileged user do that is mitigated with hardware enforced secure boot.
Most distros are holding onto 90s designs that are very hard to change once established.
Did you actually try or are you provocatively speculating?
I do have non sudoers groups devices and I also have shared devices with non sudoers users. It works. It's not necessarily for everyone, e.g. not for powerusers who want to go fast very often, but it's definitely usable for most users still.
But what exactly are you protecting then?
Linux root/regular-user model comes from an ancient time with multi-user architecture where you defended against one user taking over a big machine they didn't own.
But today on personal computers all the good stuff is inside regular users accounts, and there is nothing valuable to be gained by becoming root.
So the whole security model is broken, it protects the OS system files that nobody cares about, while allowing any piece of software complete access to valuable user files.
Well you of course want to sub-divide every application in user space either with gvisor or a hypervisor, like QubesOS.
If someone pwns your personal browser they should pop out into an environment where nothing exists but that browser, with no idea the work browser is in a sibling vm.
on Windows the UAC (GUI sudo equivalent) requires actual user input (keyboard, mouse) on a dialog presented in a secure way (can't be faked by malware)
Windows and Mac each have well thought through and secure solutions to these problems. It just doesn't exist on Linux without serious sacrifice of UX.
UAC is only a sudo equivalent when running under a non-admin user account, at which point it's nearly as convenient to simply run admin commands from a command prompt running as a separate user, or a separate desktop session entirely.
The Desktop Linux equivalent to that would be Polkit.
Psst. There's also this, in typical KDE style: https://github.com/aeroshell-desktop/uac-polkit-agent
Sudo isn't security theater when used for what it was designed for. It's useless for constraining apps you run as your own user ID.
I challenge anyone to name even one thing that requires sudo on a Linux desktop not better handled with systemd user units, Linux Capabilities, rootless docker, etc.
How would you install packages (or update the kernel)?
For root filesystems I am recently favoring EROFS which is read only, fast, and can run from ram.
On workstations I install almost all software to ~/.local as the home partition is writable. I also put all my systemd user units there, so I can run any binaries I compile as a system service to survive reboots as I like all without root.
The system root partition should contain a kernel, init system, and run any essential shared services unprivileged and fully/mostly stateless. Given that, I like to compile them all into a single UEFI uki image that contains efi shim, kernel, init all in a single binary that lives in the FAT32 UEFI partition.
The only reason to touch it is when you need to update your init system or kernel, which were always going to require a reboot anyway unless you get really creative with kexec. In an ideal situation the uki bundle is so generic that it is built deterministically in multiple locations and signed with a secure boot key. Then you can just straight up allow users to write to the boot partition, knowing any unsigned image that is not newer than the current one will be detected and also not allow access to the encrypted disk. The permission for that one update path can and should be external, and the result of a deterministic build matching a known hash, so you can prove it is not compromised. This could of course be automated by a distro with a UEFI wrapper or coreboot so users with no desire to customize their kernels do not have to think about it.
I am pursuing these ideas in stagex, first for secure enclaves and servers where we need it most, then for desktop. Until then Qubes is the least bad option.
To summarize:
stickynotememo: "How would you install packages (or update the kernel)?"
You: «You'd use sudo or su (of course) but I'm going to distract you from that with an advertisement for the work I'm doing on my personal project!» [0]
But, perhaps I misunderstood what you wrote. So... I'll ask stickynotememo's question in a different way:
If the answer is something like "I'd rebuild the read-only root partition with the new code.", then I ask:
Please keep your answers concise.
[0] Personal projects are great, and I strongly encourage them. However, the way you've answered is what a greybeard would describe as "pulling a fast one". Pulling a fast one does not earn trust.
I am not convinced you processed what I wrote, but I will attempt to answer your questions anyway because they will aid me in writing docs later.
> 1) How does the data in that root partition get rebuilt? If it's on another computer, how does one control access to the root-partition-rebuild computer?
If they use an official one published by their distro, then it is likely sufficient that it is signed by a key in a multi-party-controlled remotely attestable secure enclave controlled by the distro team, which only does so in exchange for multiple signatures from independently controlled secure enclaves that produce deterministic artifacts. The key could be backed up and restored across enclave updates using shamir secret sharing so no single engineer gets the key but they can cooperate to provide it to an enclave.
Of course this scheme to avoid trust in any single human or machine in the linux distribution supply chain only works if you happen to have a deterministic full source bootstrapped linux distribution that has strong multi-party security controls (like stagex, my "personal project", protecting hundreds of billions of dollars in fintech infrastructure right now)
> 2) How does one instruct the user's computer to use that newly-rebuilt root partition? How does one control access to the system that permits one to load a new root partition and/or change which root partition to use?
If the high trust supply chain signed UKI builds are a thing, per question one, then life gets easy here.
On first install a user would be forced to enable secure boot enrolling the linux distro signing keys, and the installer would encrypt their hard drive to that secure boot state via TPM PCRs.
Now, even though the user-accessible portion of the OS is entirely unprivileged, the user can be trusted to download new signed UKI images and place them in an update search path. Now on reboot the update will be seen, verified newer, and could be kexeced to. If it boots successfully past the uki image, a hook will cause it to move the old image to a backup file and replace with the new one, then reboot properly. Secure boot sigs pass, image is newer than old image, TPM policies pass, and disk can be decrypted. All automated.
> 3) How does a user recover when an update fails or is faulty in a way that your smoke tests didn't catch?
If the kexec test fails to boot to the hook and drops a crashlog, then the original still-unmodified UKI image stays in place, will see the crashlog, and then boot normally and warn the user about the failed update and offer to submit an Issue.
None of this is novel, though knowledge of it seems sadly rare. All can be done right now with existing FOSS, and many embedded Linux devices and servers use patterns like these. Especially in high security environments like fintech. Just configuration, admittedly a lot of it, which is what I am packaging and simplifying right now in stagex so it can be an opinionated default.
A related "Personal project": https://distrust.co/blog/enclaveos.html
> I am not convinced you processed what I wrote...
I did. There's at least one huge hole that the system -as described- seems to not account for:
> If they use an official [root partition] published by their distro, then it is likely sufficient that it is signed by a key in a multi-party-controlled ... enclave[.] Now, even though the user-accessible portion of the OS is entirely unprivileged, the user can be trusted to download new signed UKI images [from their upstream provider] ...
Distros often fail to preinstall all the software a user of a general-purpose computer needs. How does the user of this system add new system software to be used by every user of the system, rather than just the user who installed it? Suppose that the user wants to swap out the upstream-provided syslog daemon with rsyslog, or the user wants to install ghostscript for use by every user on the system... how is that done?
If the answer is something like "The user builds their own root image and signs it with keys that they manage, and then loads it into an update server that they control so their computer can automatically update to it.", then that's equivalent to using sudo with a ton of extra steps. If the answer is either "They use access control and elevation systems that means they're effectively root to augment the software load on the read-only '/'." or "Don't be daft, there's a single user on the system." well...
What mike_hearn said to you is also quite relevant:
> ...if all the apps that matter are installed to ~/.local then you're just removing the need to obtain root at all for most attacker priorities.
EDIT: There's another way a user can get new usable-by-all-users software on their root image: "Ask their upstream provider to add the software the user wants to the image and hope that they both accept the request and process it in a timely manner."... just like was done back in the days of glass teletypes, thin clients, and netbooted PCs. My recollection of (and participation in) a relevant slice of history might be why you think that I didn't "process" what you wrote. All that the system you describe seems to add is boot image signing... and I'm certain that ultra-paranoid sites have been doing that sort of thing for ages.
It's cool that you're experimenting, but if all the apps that matter are installed to ~/.local then you're just removing the need to obtain root at all for most attacker priorities.
A bit more than experimenting. I have designed several security hardened linux operating systems for major financial institutions.
There are many well established patterns for further segmenting user workloads, once far removed from real system root which is there is no good reason to expose. In my case each of those unprivileged apps runs in a dedicated virtual machine because I use QubesOS, though for many use cases gvisor or even containers (user namespaces) would get the job done with less overhead.
gvisor in particular helps you further reduce attack surface for root. It is possible to have your baremetal kernel not even have network support compiled in, and delegate all networking entirely to user-space inside gvisor.
But very few people are using their systems in ways that fit the Unix security model, which was designed for multi-user mainframes with only trustworthy software.
Nit: Unix was designed for multi-user minicomputers.
When Unix was designed, the smallest computer anyone could buy was about the size of two of today's server racks and was called a minicomputer.
But if an attacker can put arbitrary code into your .bashrc, you are already executing arbitrary malicious code.
Same if an attacker can run arbitrary docker commands.
but not as root
Yep, but pretty much every single piece of software you've installed on your system can read and write files to your home directory in a silent way without root, and that's where your most important files are on a desktop machine (API tokens, secrets, client projects, etc.).
I have my own opinionated Arch / niri set up and there's 1155 packages installed. That's 1155 opportunities for a package to be compromised. This is also why I try very hard to avoid the AUR and only use it as a last resort (I use 2 packages from it). It doesn't guarantee safety but the official Arch package repos do seem to have more checks and bounds vs the AUR.
Arch at least mandates author signed packages which is unfortunately rare these days, but keys do not need to be on smartcards, and code review is not enforced. You compromise the right arch maintainer and you could do some real damage.
Arch is second only to Guix in terms of supply chain security for desktop distributions, but both still have a threat model that cannot tolerate a single laptop compromise.
Stay tuned for stagex for workstations. https://stagex.tools
I do know some of the arch maintainers (e.g. dvzrv IIRC) are working on build infrastructure that would completely automate the build process and HSM signing to separate read-only images on build servers[0, 1, 2]. I haven't heard about updates to buildbtw in a while, but development seems still somewhat active and signstar is mentioned now and then at some conferences. It feels like it is not making any progress, but I don't pay any attention to the development, so it is likely just my perception of it just having been waiting on visible process to it and not seeing it.
[0]: https://gitlab.archlinux.org/archlinux/signstar
[1]: https://gitlab.archlinux.org/archlinux/signstar-os
[2]: https://gitlab.archlinux.org/archlinux/buildbtw
I am aware of their work, and while this is better than the status quo, it does even come close to my threat model of "trust no single computer or machine" which is what I must support.
Funnily enough it wouldn't work for me as I use passwordless sudo thanks to PAM-U2F with a YubiKey Bio. I mean realistically speaking it probably would as I would just type it thinking "Hmmm weird" but still want to proceed forward ¯\_ (ツ)_/¯
Of course this style of attack would work on you. Attacker has the sudo wrapper that hooks your next yubikey tap to running any payload they want as root.
Your solution helps mitigate hardware keyloggers, which is great, but for malware in your home directory, it offers no advantages.
I'm missing something then, are you talking about the code your shared or an another slightly more complicated one you are just imagining now?
A 3 line change to my above code would do for your case. Obviously that is not production ready malware, it is just a minimum viable example for the most common target.
You type "sudo" and it runs an unprivileged sudo wrapper, and prepends your sudo command and runs real sudo. You tap, and your intended command runs as root alongside the attackers command.
You need a separate trusted OS to do privileged workflows from. Your setup would be effective if you were using an OS built for that kind of thing like QubesOS.
In my setup every app runs in a dedicated VM with a fake proxy smartcard, that routes to a real nitrokey in a hardware isolated and offline VM. That offline VM can be like "do you want to authorize a tap for aws.amazon.com" and I can be like "not today malware. I asked to login to doordash. nice try"
Desktop alternative to most uses of sudo: Polkit[1]. For a UAC style prompt, see AeroShell[2].
However, one still SHOULD NOT allow untrusted software arbitrary read/write access to their $HOME, even on a completely secure (and thus, imaginary) OS. No reason why every App X should have access to the files of every App Y.
1: https://wiki.archlinux.org/title/Polkit
2: https://github.com/aeroshell-desktop/uac-polkit-agent
It’s not great, but I’m not sure this should be framed as Omarchy-specific, when it’s a very common setup to add regular user to the docker group.
>when it’s a very common setup to add regular user to the docker group.
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.
Adding your user to the docker group is in the official Docker install instructions, I wouldn't call that "random copy paste guides".
You mean the optional post install instructions, which is a separate page from the main install instructions, and contains a giant warning about the security implications?
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.
Per my other comments, it does not really matter if you disable the sudo password or not. If you have a sudo binary at all you effectively are giving every user process root since malware can mask the sudo command and intercept the password so trivially.
The methods are described on the official docker website, not just random blogs or SO pages. There are caveats about security, of course, but it's not truly discouraged.
I think there are notes that warn you about the consequences. And they have been written with sys admin in mind which knows about user groups and security.
You mean, just how it is on Windows?
It is one thing to do things the risky way on your own system and another thing to ship an unsafe and unconventional default to your users.
For a single user, opinionated, modern, developer focussed OS, this is completely and utterly on par. Using docker as a developer without this is just plain annoying.
Just use podman, as the article suggests.
Too much stuff doesn't work with Podman still.
Especially if you're on an SELinux system.
This also seems like one of the more common things LLMs use to priv escalate themselves when not given root access, seems like a rather common misconfiguration.
Using Docker instead of podman is the first mistake and that is a distro decision (or a "chef" decision, in Omarchy parlance...)
*rootfull docker.
Rootless docker is perfectly fine.
Docker can be run rootless. It is so easy. No excuse for desktop distros to not do this by default. And that is why all major Linux distros are just as bad as Omarchy (Not recommending MacOS or Windows either as those are wildly worse)
> but I’m not sure this should be framed as Omarchy-specific,
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.
Exactly! I was also surprised by this — that's a sensible default for many people.
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.
It's absolutely not Omarchy-specific, Ubuntu has the exact same vulnerability out of the box, just with lxd instead.
> Ubuntu has the exact same vulnerability out of the box, just with lxd instead.
No, it does not[1]. LXD:
- explicitly warns against this mode of vulnerability. Of course, there's no protection against people who blindly run commands copied from the internets, but the official documentation, at least, for as far back as I can recall, has had clear warning boxes against this, with explanations.
- does not have the track record of bad design that docker has had (IMO).
- supports fine-grained ACLs and user management.
----
[1]: https://ubuntu.com/blog/shared-development-environment-with-...
Yes, it does. None of this information changes the fact that, on a fresh install of Ubuntu Server 24+, the default user can privilege escalate to root using a few LXD commands.
https://starlabs.sg/blog/2026/06-old-wine-in-a-new-bottle-a-...
And yes, I've tried it myself, it works as advertised.
Docker itself is such a massive security problem. Like it’ll punch through your firewall. Found out the hard way after a misconfigured redis was exposed to the web.
Why not use rootless podman? It is 2026 not 2016, Podman works much better than Docker today.
that's what I do and what the author recommends as well
Somehow I doubt DHH and company would be OK sacrificing ""developer experience"" for security... There is still a non-trivial amount of docker-compose files and Docker incantations that don't work 1:1 with podman and podman-compose. Adjusting them would require Omarchy's users underatanding podman, and I doubt this will align with the opinionated nature of Omarchy..
Come on. I am sure you don’t like DHH. But he’s always taken security seriously in Rails.
As I said, podman requires effort and thought on the user's side, as the rootless part incurs complexity. I do not think that this aligns with the omakase mantra of omarchy. I do not think that DHH does not take security seriously. I think that Omarchy is not meant to sacrifice devex for security.
Rootless Podman (and rootless Docker for that matter) is not difficult to set up automatically. There is a little complexity involved, namely in configuring subuid and subgid mappings, but not much.
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 was not referring to the setup complexity. Setup is performed just once. I was referring to the runtime complexity that comes naturally from having to take into account non-root user permissions and lack thereof. These peculiarities are quite a low bar, but they are still a non-trivial hurdle in the way of devex.
I am a fedora/opensuse user and happily use podman with selinux.
IME it's not too bad, but I see what you're saying. I guess we're mostly in agreement.
Shopify forced him to be a vibe coder now. Omarchy is a vibe coding distribution.
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.
It's really disturbing that there's a group of these CEO/investor types that are openly white nationalists, and they're joining forces. I'll never touch any of their products, and I hope they continue to expose themselves on social media.
Omarchy is an agent first experience, no? just ask your agent!
Don't use podman compose unless you want to have a bad experience. Play kube is podman's API for orchestration.
The article specifically calls this out as a preferred option.
because the distro is all about convenience over security, while selling an aura of technical superiority. Which is the modus operandi that worked for the distro author in the past, when he sold VPS with a big markup, because he also gave a script that did "ssh vps -- curl somebashscript" to do basic webdev taks.
> 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.
I've used docker until recently just because it was what I was used to. It turned out I can basically just `apt install podman` and it'll just work. I might have stayed a bit behind the times with having podman slotted as a redhat thing.
Rootless docker is also an option.
> Podman works much better than Docker today.
Nah absolutely not. Especially compose files and networking can be an absolute nightmare with podman.
Compose files work just fine. The gap with Docker has basically closed, and the few things you can't do or that behave differently are precisely the things Docker shouldn't be doing.
Is it opposite day already?
The Docker configuration issue was reported and changes were made quickly to address it. Sounds like this is a great example of the system working well.
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.
Gatekeepers? Someone is pouring something into your ear.
It's easy to disable rootful Docker support in an ISO, but much harder to fix the vulnerable installations. That is not the system working as intended.
And sadly, this stuff isn't bewildering at all. We saw it happen with LARBS, we saw it happen with Manjaro, then Archlabs, and now Omarchy too. All of them endangered themselves by shipping dotfiles that none of their users understood, and few of their developers would justify. When Manjaro's repos conflicted with AUR pkgbuilds, thousands of their users didn't understand that Manjaro had a special repo override for system packages that lags 2 weeks behind upstream. Omarchy tempts the same fate by stacking custom packaging channels and pacman scripts on-top of a system that gets advertised as "regular" Arch Linux.
Distro variety is always a good thing, but there has always been different levels of commitment to it. If I was putting together a Linux system for a kid or someone elderly, I'd just give them Fedora/GNOME instead of trying to get them into larping r/unixporn.
Personally, I wouldn't recommend any Linux distro other than Manjaro with XFCE, for a non-expert, because it just works and installing software is a breeze with Manjaro's graphical UI (pamac).
I've been running various Linux desktops since the late 90s and every single distro without exception has eaten itself from updates...except for Manjaro which I've been running exclusively now since 2018 without so much as a hiccup.
Two-week old packages is nothing. The most popular Linux distributions aren't even rolling distributions and they'll have you using packages that are years old.
Why do you think people that disagree with your opinion are gatekeepers? You can still use it if you want, no one’s gate keeping anything lol.
No one serious about security touches Omarchy.
Practically every distro suffers from critical LPEs, but at least there’s a bar.
Omarchy is a hot mess that exists for the same reason that matcha is in our coffeeshops and peptides are in our collective memory.
This is a weird metaphor - why do you think people buy matcha at coffeeshops or use peptides? Those two things don't have anything obvious to do with each other, let alone with Omarchy.
except that all three things are getting a lot of social media clout.
they just keep pumping out short form videos or yapping heads talking about how they use x to do y better than any of the old stuff...
I think this is the OP's point. they all exist because there is a lot of noise about them existing and being used.
Thank you, that’s it exactly.
Genuinely so confused about your last sentence, please explain…
Wow... this is really telling. This isn't some obscure whoopsie. The docker install page has a giant section explaining exactly this problem. Every Docker section on every distro wiki walks through this issue in detail. It 80% the reason Podman was created in the first place.
Ubuntu is good enough. I never got the point of tiling window managers, because the most important part of daily computing, browsing the web requires you to use the mouse. I’ve tried keyboard only browsers, none of them are as intuitive as just using a mouse and they can’t be, especially considering the prevalence of hyperlinks.
I guess while coding it is nice, but I can switch between the terminal and my editor in a single key in Ubuntu itself so I don’t see the point of this.
vimium is my solution to the web.
Valid, but I’m unsure if mouse use needs to be mutually exclusive with a tiling window manager, and would like to suggest that all tiling managers are not necessarily made equal.
Niri for example, tiles but additionally introduces an infinite horizontal space, where you can slide between different windows like they’re on a film strip. The slide into view works with a mouse, and you can easily setup mouse bindings to move and reset windows. I think it’s better than just a stock floating windows manager because it feels easier for me to navigate an infinitely wide left-right and up-down space as opposed to an infinitely deep space into and out of the screen.
Omarchy has me questioning liking Rails because it just… straight up sucks?
It comes preloaded with friggen ZOOM. I don’t think Windows bloat is that bad.
If it makes people happy it makes people happy I guess. These guys trying it would be even more amazed at Fedora Workstation (“you can press windows and it shows all your open windows? That’s so much better”)
i don't understand why DHH is shipping so much bloat in omarchy. The better solution would be to ask if user wants to install bloatware during installation.
DHH created a distro for what he personally needs for work, and his company uses Zoom.
It's that simple.
There are far better ways to handle setting up a workstation for one's needs than spinning a new distro.
Perfect example of a usecase for nixOS. Single file and its got everything DHH wants.
Thats pretty good, then he should have made a toolkit for building and rolling your own badass distro and not a "opinionated" "omakase" system that claims to solve all of deskop linux while personally mocking a lot of people that actually have made real contributions as "clowns".
His tone is horrible. Because he implies untrue things while being 100% certain. He will paint entire communities as against omarchy when it’s just a couple left wing members with a stupid take. It doesn’t help the distribution is just … not that good.
Well, DHH is a moron. I don't know if he always was, but he clearly is now.
By doing open source and sharing his opinionated setup with other people ?
No, probably the other thing.
dhh understands what a good user experience is. Installing in a couple minutes and getting right into it is an amazing start compared to most operating systems that take ages to setup.
Plus, many pre-installs (like Zoom) are web-apps that take no space (30 lines of text) and are easy to remove if you don't want them in the menu.
Have you… used any other Linux distributions at all? For longer than a month? Respectfully. The thing DHH killed was demoing Omarchy most stuff is in other distros out of the box. And like installing in a couple minutes is table stakes.
Have you used any of the popular distros? They all ship with loads of bloatware by default
Like what???? I don’t revolt at anything pre-installed on fedora.
And arch Linux specifically ships with nothing!
6GB is 3x larger than most other distros. It is kind of mental.
I don't find it to be too bloated, and the things I don't like I simply uninstall.
So far its the best Linux Desktop experience I've had, and I hardly have to configure anything out of the box, most of it just works.
That’s awesome! Everyone has different tastes. Personally I love GNOME because it’s extremely productive and works out of the box.
Yeah, GNOME was my previous preference, but I don't see myself going back now
Learning the hotkeys in Omarchy is a bit of a process, but there is a hotkey to show the hotkeys lol (super + K) - and once you get used to them, its super productive, at least to me.
(Not a Rails developer, just an outside observer)
Isn't Rails highly opinionated with a focus on being batteries-included? I'm not defending the choice to include Zoom but a batteries-included (for better or for worse) distro is exactly what I would expect from the creator of Rails.
I guess I love highly opinionated stuff only if I agree with those opinions.
A lot of the "pre-install bloat" are just web apps, including Zoom. Zoom is just an 8 line file so it appears in the menu and to point it to a 22 line bash script to launch the app.zoom.us website at the right address.
Easy to remove. Can even open your favourite AI assistant and ask it to remove it, since it comes with an Omarchy skill and knows how to change everything.
> Easy to remove
See this is where its going too far IMO.
When you setup rails, you get far fewer "batteries" by default.
Its batteries included, but opt-in to be included.
That is totally different from installing an OS and having bloatware already included.
It'll get there with enough community support hopefully, but the current state is very rough(much like early rails)
Somebody should do an audit of Omarchy Plugins: https://plugins.omarchy.org/
They run completely unsandboxed and are unvetted.
Installing docker by default is completely insane. What are they doing? Rootless podman has been around for many years at this point.
Rootless docker is even an officially supported install method.
Friends dont let friends use Omarchy or [claw] products.
I had no idea what Omarchy was, so I looked it up: https://omarchy.org/
Is there a name for a phobia of yt thumbnails?
Yes.. taste
I was expecting a more sophisticated attack and then I scrolled down…
> 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.
Because it's convenient, and the security of this doesn't matter for desktop usage.
lol. people will vote you and not realize the irony.
just look at all the comments "this is a fair and common mistake" that are not being ironic.
Default configuration or not, I also imagine the first thing people using docker do is to add themselves to the docker group via sudo.
If you are security-conscious, you shouldn’t be using docker anyway.
If you are adding yourself to the docker group, you have presumably read the documentation and its warnings. Does an Omarchy user know the distro has made the decision on their behave?
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 am not disagreeing at all. Nor am I trying to claim this behavior is safe.
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.
I have passwordless sudo anyway. XKCD knows why the password is pointless.
> 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???
Isn't that the entire selling point of Omarchy?
There is a major difference between uploading your dotfiles to github and shipping it as a mass-marketed distro.
At the very least they could have documented this sort of security trade-off if it actually is an intentional choice.
I didn't know that was unsafe.
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.
I don't use Omarchy, nor would I, but I think that "VERY, VERY" is a little hyperbolic, no? It's a simple `admonish-yellow` warning box that says something vague about root-level privileges and wants me to read more about what this actually means. I would wager that a large amount of people scroll past that with no second thought because it really doesn't come off as that bad. I know I configure most, if not all, of my systems this way. Many people probably don't actually understand the implications of what they are doing, and perhaps the Docker team should actually put a little bit more effort into scaring users off.
Perhaps Omarchy shouldn't have shipped this by default, but the whole point of the system is to be DHH's personal computer just the way he likes it (to include not 1, but 2 shortcuts to Twitter!) - all his products are that way and largely the reason why I don't ever think I could use one long term.
Once you have a box vibe coding has happened on I wouldn’t trust anything on it. Thats why I vibe code on a fully separate machine.
Im not an Omarchy user but we now live in a world where most of the actions (including ones the llm asks users to run as root) originate from somewhere other than the users brain.
There will be a reckoning in terms of how we think about trust and auth in coming years. It’s just a matter of increasing severity of incidents .
The docker escalation 'trick' is even a meme at this point
As expected from a vibecoded "distro"
There are definitely a few security holes in Omarchy. I tried installing their win11 docker script and that just saves the username and password of the Windows VM as plain text in a config file.
I like playing around with Omarchy since there are a lot of interesting ideas put together in a semi cohesive 'OS', but would probably not use it for anything serious until it became a bit more mature.
you probably mean win11 vm script, that's not really a security hole, as the host running the vm you are basically root on windows anyway, unless you bothered to encrypt the drive inside the windows vm
My most controversial opinion by far in tech circles is that I still just use a standard Windows gaming PC as my home desktop. My current machine I just bought pre-built from Microcenter, complete with a 5090 and everything.
I can fire up a Linux terminal with WezTerm and WSL2 at any point. It's customized and beautiful and totally fine. I have Codex running in one right now. I can listen to Dolby Atmos music through Apple Music or fire up a game with zero compatibility issues and full RTX support. It's just versatile like nothing else. I pair it with a gigantic 48" LG OLED TV as my monitor.
The only thing that might tempt me away from this is a fully loaded Mac Studio with 512GB of unified memory. That would be a real capability gap from my current machine. But I've contemplated wiping Windows and installing Omarchy, and I just can't figure out really what I'd gain, but what I'd lose is quite clear.
Has it restarted losing your session to install an "Intel Corporation - Extension - 22.1120.5.12" yet?
Windows has also come a long way from a terminal perspective. Sure, the UI is a bit of a mess, but Powershell can do anything in the UI from the command line, and agents are very capable with PoSH. If you really care about ricing the UI, there's hundreds of utility apps to do almost anything you want.
Agents are also able to tweak and debug Windows errors, since the registry, group policy, event log, and other Windows internals have been largely unchanged for 25+ years and are well documented. All have old command line tools or modern Powershell to manage.
you have to understand that 90% of HN use macs and the only time they see windows is once every 5 years when a relative asks to setup a new or clean an infected one
there is currently no linux distribution where it's safe to run an application as is. they tend to have access to /home which is game over.
some people who actually care about security will create bubblewrap/bwrap profiles for applications and then run those profiles. an application isolated in this way will have a limited view of the system much less the ability to modify it. it usually takes the form of a custom /home for every app.
this still leaves the kernel exposed for an application to poke at and maybe escape with a 0day. some people run a VMM to further isolate the application, these days you can passthrough Wayland. if the application isn't graphical you should probably use gVisor instead.
Not an Omarchy user and use podman rather then docker. But is this not a docker issue rather then a Omarchy issue, docker should verify user permissions through the socket, it's quite bad that it does not no?
Sorta, but there is a reason that no other distro does this by default and that docker itself warns that doing this is effectively giving the user password-less sudo.
So this is a problem in Omarchy specifically since it does the dangerous thing silently and by default while everyone else tries to inform the user of the consequences.
I see, if it's common knowledge of people who use docker that rootful docker is root (though this does seem bad and they should just check the user perms at least) this sounds pretty terrible on Omarchy's part.
And the cycle continues. It’s funny seeing Omarchy (DHH) becoming popular when we had LARBS (Luke Smith) 8-10 years ago.
Something about a controversial personality pushing a window manager install script is really appealing to people I guess. At least it brings awareness that other desktop paradigms exist. Although after years of ‘optimizing’ my tiling window manager I just ended up back on KDE.
Debian + KDE is the most effortless setup I've ever used. I also spent years using tiling window managers and I don't see the value
"That Luke Smith?" Yep.
I hate to be defending Omarchy but I think for the modern desktop OS like Linux or Windows or Mac OS, "root" is not what it used to be.
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.
I would say that the traditional notion of Unix root and normal user accounts is outdated, no longer useful for how people use computers today. On my personal laptop, malicious code having access to my user files is as bad as having root access - I'm the only user of my machine - and I don't have any convenient way to create more granular security zones among software running as my own Unix user.
I can't fathom why it's so common to run docker as root instead of as an unprivileged user.
Docker has supported running rootless mode for years. I packaged the docker-rootless into Arch/AUR over 4 years ago, so it's been around and stable that long.
Sure, on a server dedicated to running docker containers, maybe it makes sense for the marginal improvements to network latency. But otherwise, rootless should always be the default.
Inertia. All the guides tell you to set it up the "easy" way.
There were many amazing distros before Omarchy and there will be many after. Use whatever you want, vibecoded or not. Don't tell people what to do. Make your own decisions.
Bigger question is does Linux need another distro at all?! I would say about as badly as Singapore needs a mall.
There's no doubting the brilliance of DHH and folks working on it. What if that went to into making a better UI, Desktop like Mac. After all Apple did that so well when they moved to Unix core.
Barely related, I decided to move on. Linux has been weaponized for self-promotion. So I'm happy just working with Beastie these days.
I don't know much about Omarchy but this seems like a common way to use docker even on Ubuntu. As far as I know it's in the official guide. Why are so many people hating on the distro?
anecdotal and fwiw, Omarchy is the first distro that "stuck". I've been using it on my desktop for a year now. I use it for personal projects and light gaming via Steam. Personal MacBook is only used when I want to compute on the couch. Work computer is also a MacBook. But everything else, Omarchy desktop.
Previous attempts with Ubuntu and PopOS! never stuck.
Debian 13 is good.
OK... and? This doesn't matter for a desktop, because:
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?
https://xkcd.com/1200/
Because it looks cool and DHH makes a lot noises that sounds like you should listen to him.
And he politically aligns with a lot of people.
Lol! He's gordon ramsay of tech, who's frequently contradictory himself. On Round 2 with lex, he said something like no one lost recently due to using digital Maps. Well, check this one - https://youtu.be/z5ElIor-oXk?si=XfcS1UtC2OWReVXr
He's bashing and insulting all engineers and then asking for their contributions and complaining that not many people are committing code in open source repos.
Because they like their Arch setup? Because installing Omarchy is three to five minutes at most so three to five times faster? XD
The point is that there are millions of people out there that are curious about Linux but are put off by anything command line. Distro like this, especially Quatro which has a big focus on agents, makes it more inviting and gives people an instant path to get help/have their problems solved without them having to search archaic error messages
Because it works out of the box unlike a lot of other distros
The scenario of running any agent on the host raw seems far fetched for most users. I think everyone is running these things in at least a container, I know I never trusted running claude code or any agent for that matter, but I might be a little paranoid on that front.
Out of all the commentators here actually running Linux Desktop, I wonder how many have used Omarchy? To me its the best Linux desktop experience I've had without having to overly waste my time configuring things.
Poor software choice for usecase. `sudo pacman -S podman` didn't come with these problems out of the box and assumed rootless by default.
Is it not better to run a VM just for Docker, like we have to do on macOS?
That has all sorts of issues like eating disk space and RAM, because neither can't be released to the host once allocated, but then become unused.
At least is secure(tm)
I just want to put this out there, smolmachines is a wonderful program to solve this, I use this mostly for stuff needing docker socket / docker in docker (example strix and agents). (I'm using podman on my host)
At that point why not just simplify things and go back to Vagrant...?
Damn, I did not know you need a VM for Docker on macOS. That's kind of ironic, isn't it XD
Every day I wake up and thank the universe for MS making WSL2
Isn’t WSL2 vm based?
WSL2 is also a virtual machine.
WSL2 is also a VM. docker relies on the linux kernel apis, so it must be ran inside a linux VM on macos or windows
Windows does have a native sandboxing API that Docker is capable of using IIRC, but nobody uses it.
The macOS situation is even worse in that the kernel lacks the requisite capabilities.
I’d rather run real Linux in a VM than a buggy appropriation of it in WSL
What on earth is an Omarchy
Officially omakase (clueless chef decides your menu with security issues) and arch linux.
The fact that it is almost an anagram of monarchy is probably a plus for DHH.
You realize you are exemplary hater when you feel an urge to post comments like this
You are absolutely right and I'll have Claude read a ChatGPT summary of Paul Graham's hater essay!
> The fact that it is almost an anagram of monarchy is probably a plus for DHH.
I spend way too much time online; but it's good to know I am not this terminally online.
Thank you! Sounds horrible.
I don’t know what a DHH is though, probably not important.
The guy who invented Ruby on Rails. He’s been pretty important in web dev and he’s an excellent engineer, although he’s a polarizing figure. He’s always been opinionated and never afraid to ruffle some feathers. More recently, he’s been posting some controversial right-wing stuff online that pissed off a lot of people.
Yes ok, but the moment you gain user access to my machine, I've already lost. The amount of damage you can do as root is about the same you can do as me.
Docker should never be used as a sandbox for anything.
Surprised by this. I only ever use podman (which by default, runs rootless) these days and haven’t felt the need for docker. Feels like reading about a CVE in Compiz.
This is the type of security and vulnerability testing that actually matters. In a sea of security researcher noise, thank you for contributing in a meaningful way.
Couple of months after this discovery, Internet explorer 11 will be released (October 17, 2013)
Lol. This misconfiguration is so common and so trivial that LLMs have been known to exploit it unprompted, to complete their task.
And here it begins…
Been using Linux on and off for 30+ years and I’ve always always had second thoughts about using anything outside the main 3-4 distros, and I mean forks, blends etc. let alone vibe coded distros, even *buntu feels like a stretch.
I really like DHH’s enthusiasm and what he’s trying to do but I will never touch that “distro”.
Debian/Devuan, Fedora/RHEL/Alma/Rocky, Arch/Artix, FreeBSD/OpenBS/NetBSD are all anyone will ever need.
You feel more adventurous? NixOS, Gentoo, Slackware, Void.
That’s it. No forks, no blends.
I keep Xebian and LMDE ISOs in my flash drive to show people but I don’t personally use even those.
People jumping all around these new distros that only seem to change a wallpaper without knowing the basics is a bad choice, like the first comment says, isn’t this the reason you wanted to move away from Windows in the first place?
Just take your time and enjoy learning, they are all so simple today compared to decades ago it’s crazy.
Thank you for listening to my TED talk.
Ubuntu has the exact same vulnerability, except with lxd instead of docker, but for some reason, it's considered working as intended.
On a fresh install of Ubuntu Server, the first user created is part of the lxd group, can install lxd without root thanks to snap, and can immediately create a privileged container with the host's root filesystem mounted inside.
I genuinely put companies that invested in this on my blacklist. I don't care about the politics behind it. His whole persona is and was to be edgy and cruel so nothing will change here. But there are probably millions of oss projects that deserve the funding more.
"Opinionated" software sounds great until you find out the author has the stupidest opinions you've ever heard in your life.
and in this case that's even before you get to the software opinions
Why is it always the people with the worst opinions who make the most stuff though? Why aren't the rest of us making popular stuff?
To put out something that is opinionated, one needs to risk others being critical of their opinions. People who are always worried about having the “right” opinions will rarely risk stepping out and doing something different.
So all the safe boring stuff that gets released is just a defense mechanism, where people avoid going too far in and direction to avoid being accused of having bad taste. Ironically, this creates its own lack of taste. This lack of taste is usually just ignored as boring, rather than attacked, so it feels safer.
At least that’s my read on it.
AFAIK, Fabrice Bellard has normal opinions.
Is there a place he shares them?
Refreshingly, no.
docker access == root, as long as you can use volume mounts to arbitrarily mount anything else on the machine to a container. If the user is in the `docker` group, he's effectively root because he can patch around system files.
I once used this to recover lost sudoer access to a machine (have tested this now by editing my sudoer file with a comment):
~ docker run -it --rm -v /etc/sudoers:/etc/sudoers ubuntu bash
# apt update && apt install -y vim
# -- edit /etc/sudoers
# wq!
~ exit
~ sudo cat /etc/sudoers - works, comment is present
It's disappointing to see the way the developers are pushing this pre-alpha quality work. I don't know (nor care) about the personalities attached, but the pitch is neat. The way it is being handled with almost daily reports of RCE/Escalation is jaw dropping though. They need to spend some of those bux on auditing and less on whatever vibe-based engineering they're doing.
For haters: ignore them and recommend your favourite. For lovers: lobby the developers to raise their standards.
why would anyone use this distro when there are so many options? genuine question.
DHH is an influencer and people like to follow them. I know I did 20 years ago when his videos influenced me into saving for a MacBook. He basically meme'd web dev with rails on TextMate.
That's the point of omarchy. There are no options. You boot from iso, enter your name and press enter. After a minute you have a working system.
Basically every other distro is: choose one of these 10 filesystems, 5 bootloaders and 20 desktop environments
This is not true. Plenty of distros are dead simple to get started with. Including the most popular ones like Ubuntu.
If you editing your system config with an LLM and tool calls, why wouldn’t you just use NixOS. At least if the agent broke your system, you can basically recreate it from scratch in under 30mins (some things still might be outside the system/home-manager config). But yeah, then you get diffs of what the agent changed in a nixos/home-manager change.
I see almost zero reason for anyone to use anything else for they’re base system at this point.
I mean, I saw this on twitter, and thought ok maybe its a nice exploit. But really? its the usual docker root thing?
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]
I am a little unsure why folks keep getting convinced one new distro or another is gonna come and finally solve the Linux desktop adoption problem?
The fundamental problem linux distros have is that they dont agree on a fundamental set of libraries, user experience, or have a stable abi. We've had minimal disros before, we've had maximal install-everything distros before, and we've had special purpose distros before (ie knoppix, mythbuntu, Kali). But the same adoption problem remains.
Afaict Google and Valve have managed to meaningfully move things forward with chromeos, android, and steam OS. Tools like flatpak and others also have made a difference.
But if you're really going the typical distro route, it confounds me what the point of going outside of the typical and common debian/redhat/arch systems are especially when its one guy. Hell, I still remember SprezzOS (Nick Black's Distro) and that thing had more real goals worth praising than anything I see from Omarchy.
I don't see a responsible disclosure timeline, putting doubt on the black/greyhat hacker, but am not surprised this was patched post-haste, unlike some less caring operations.
In any case, another reason to upgrade to Quattro! I just hope my 30€ Chromebook can handle it as well as it handled 3.
That's some fame now.
The likelihood of Omarchy being hacked is no doubt compounded by the number of enemies DHH has created who would love to see him fail.
>the most important takeaway is simple: update to 4.0.1.
I gotta say, that is not the most important takeaway for me; rather, "don't walk, run".
That is what happens when someone without a clue what is he (khm, DHH) doing vibe codes a distro.
Other day i was hearing DHH talk on Lex's podcast on Omarchy and how he does not look at the code anymore. The guy built solid reputation with his prev contributions but now falling to AI slop.
He must really be all in on AI to be interviewed by one.
He said he still reviews code, just for some tools he's vibe coding for himself he didn't look at the source.
No way, the vibecoded distro has security problems!?!?! WTF, didn't DHH ask claude to check for security issues?
10M for a some shell scripts what a steal lmao
I've already stated this on the last Omarchy thread, the way DHH is implementing it is highly irresponsible and insecure. Half of his "distro" are essentially shell scripts where it's extremely easy to create accidental security holes. Considering that probably half of his code would need something like setuid/execute bits set in order to avoid configuration spaghetti, I'd imagine that there are _hundreds_ of vulnerabilities in there. If you think about it logically, just the desktop environment (note that I have no idea if he coded his own or is using an existing one) needs access to input the graphics driver the netstack all of which require priviledges of some kind.
He did not code his own desktop environment, it’s just hyprland.
Sad that people just complain about what DHH is doing and how he doesn't know anything. Nobody is forcing anybody to use Omarchy at all. Also $10 million was raised by him for it, did anybody else here raise that for a distro? I'm tired of the constant complaining and criticizing. Nobody said you have to use it.
Nobody said you can't complaint about things unless you're forced to use them!
Well thats what I've noticed lately here on HN, complaining is #1, everything else follows. lol.
I don't care what he's doing, I care about what he is.
He's a person, just like you are. Let him know then, he has an email and you can message him publicly on X.
He clearly "suffers" from narcissistic personality disorder, trying to change him is a waste of time. Even if he was a normal person, I see no rational reason for him to change his behavior given how successful he is.
So he’s a lost cause to you? You decided already? So much doom and gloom in your response.
Yes, he’s a lost cause: https://tekin.co.uk/2025/09/the-ruby-community-has-a-dhh-pro...
So what works for you: seeing him disappear from the Earth? He's not a human anymore? Have you ever spoken with him directly before? Or do you just read and write about people you've never had any real interaction with?
Why would I want to interact with a racist? There's millions of them on this planet and no one owes them anything.
> He's a person, just like you are.
He's not like me. I've never posted racist hate filled rants to the internet.
What he is or what random blog posts present him as?
His own blog posts present him as what he is. Have you read them?
Some yes. I am not american, so i don't see anything particularly wrong with them. The main thing americans forget is that they are the invaders that replaced the local population and erased local culture.
This is hilarious. He isn't American and isn't talking about American in his racist rants. The people calling out his racism aren't focused on America or a majority American. His main blog post that gets called out for the blatant racism is titled "As I Remember London".
Yes, he talks about foreigners arriving and forcing change to local culture instead of adapting.
Does his own blog count as "random"?
https://world.hey.com/dhh/as-i-remember-london-e7d38e64
Interesting point. I'll summarise my counter response as: fuck DHH. Guy can shove an omarchy up his jacksy.
The funding for this is to pay for a culture war, not a distro.
ot fyi: "omarchy" is fine as a creative spelling for omachi, but "omacon" / "omacom" has extremely low Levenshtein distance with the honorific form of the word for human female reproductive component in japanese
And the word "pine" is kinda close to "penis", what of it? Words in languages sometimes sound kinda like rude or sexual vocabulary, especially in a language like Japanese with a relatively small phoneme inventory.
Those two aren't as close
Was this vulnerability disclosed responsibly by the author?
Yes, it has:
> 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.