Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Omarchy: Any User Process Can Escalate to Root

0xcc.io

Post reply on HN
Print view View original

511–520 of 590 posts

Re: Omarchy: Any User Process Can Escalate to Root

#511

Post by 0l »

silver_sun wrote: post #228
0l wrote: post #100

Earlier quoted context omitted.

Indeed, and most flatpaks have access to the home directory so are also able to do this even though they're """sandboxed"""

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

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.

Re: Omarchy: Any User Process Can Escalate to Root

#512

Post by mike_hearn »

lrvick wrote: post #445
stickynotememo wrote: post #383

Earlier quoted context omitted.

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

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.

Re: Omarchy: Any User Process Can Escalate to Root

#513

Post by mike_hearn »

mosura wrote: post #147
mike_hearn wrote: post #114

Earlier quoted context omitted.

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

Any interest in such a site?

Re: Omarchy: Any User Process Can Escalate to Root

#514

Post by mike_hearn »

teekert wrote: post #160
mike_hearn wrote: post #114

Earlier quoted context omitted.

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

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?

No. We're talking about USB device names being parsed as Lua due to some window title injection issue in Hyprland.

Re: Omarchy: Any User Process Can Escalate to Root

#515

Post by mike_hearn »

Cloudef wrote: post #163
mike_hearn wrote: post #33

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…

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

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.

Re: Omarchy: Any User Process Can Escalate to Root

#516

Post by mike_hearn »

Retr0id wrote: post #156
mike_hearn wrote: post #89

Earlier quoted context omitted.

Android is basically a different OS that happens to reuse parts of the Linux kernel.

Yes, it reuses all the 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.

Re: Omarchy: Any User Process Can Escalate to Root

#517

Post by mike_hearn »

lrvick wrote: post #164
mike_hearn wrote: post #105

Earlier quoted context omitted.

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

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

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.

Re: Omarchy: Any User Process Can Escalate to Root

#518

Post by lrvick »

simoncion wrote: post #459
lrvick wrote: post #445

Earlier quoted context omitted.

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

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: How would a user of your system update the Systemd collection of software…

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

Re: Omarchy: Any User Process Can Escalate to Root

#519

Post by mike_hearn »

amluto wrote: post #166
mike_hearn wrote: post #105

Earlier quoted context omitted.

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

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

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.

Re: Omarchy: Any User Process Can Escalate to Root

#520

Post by lrvick »

mike_hearn wrote: post #512
lrvick wrote: post #445

Earlier quoted context omitted.

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

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.

Post reply on HN