Live data from Hacker News

Omarchy: Any User Process Can Escalate to Root

0xcc.io

551–560 of 590 posts

Re: Omarchy: Any User Process Can Escalate to Root

#551

Earlier quoted context omitted.

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 wi…

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.

Re: Omarchy: Any User Process Can Escalate to Root

#552

Earlier quoted context omitted.

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.

Re: Omarchy: Any User Process Can Escalate to Root

#553

Earlier quoted context omitted.

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.

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.

I implore you to give CachyOS with Niri a try.

Re: Omarchy: Any User Process Can Escalate to Root

#554

Earlier quoted context omitted.

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 o…

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?

Re: Omarchy: Any User Process Can Escalate to Root

#555
post #522

Earlier quoted context omitted.

> 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 e…

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 pr…

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

Re: Omarchy: Any User Process Can Escalate to Root

#556
post #444

Earlier quoted context omitted.

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…

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

Re: Omarchy: Any User Process Can Escalate to Root

#557
post #452

Earlier quoted context omitted.

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"

Re: Omarchy: Any User Process Can Escalate to Root

#559
post #171

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 an…

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

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.

Re: Omarchy: Any User Process Can Escalate to Root

#560

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”)

(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.
Post reply on HN