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

541–550 of 590 posts

Re: Omarchy: Any User Process Can Escalate to Root

#541

Post by shimman »

mosura wrote: post #169
itishappy wrote: post #115

Earlier quoted context omitted.

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.

Re: Omarchy: Any User Process Can Escalate to Root

#542

Post by NekkoDroid »

lrvick wrote: post #444
nickjj wrote: post #340

Earlier quoted context omitted.

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

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

Re: Omarchy: Any User Process Can Escalate to Root

#543

Post by hollerith »

inigyou wrote: post #216
mike_hearn wrote: post #119

Earlier quoted context omitted.

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.

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.

Re: Omarchy: Any User Process Can Escalate to Root

#544

Post by NekkoDroid »

cute_boi wrote: post #381
inigyou wrote: post #218

Earlier quoted context omitted.

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

Re: Omarchy: Any User Process Can Escalate to Root

#545

Post by optimisticedits »

bigyabai wrote: post #351
trentnix wrote: post #190

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

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

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.

Re: Omarchy: Any User Process Can Escalate to Root

#546

Post by jijijijij »

mjmas wrote: post #355
jijijijij wrote: post #332

Earlier quoted context omitted.

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.

Re: Omarchy: Any User Process Can Escalate to Root

#547

Post by killix »

kodoman wrote: post #303

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.

[flagged]

Re: Omarchy: Any User Process Can Escalate to Root

#548

Post by treebeard901 »

troupo wrote: post #509
treebeard901 wrote: post #357

Earlier quoted context omitted.

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

> 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

Re: Omarchy: Any User Process Can Escalate to Root

#549

Post by oneplane »

Cloudef wrote: post #474
oneplane wrote: post #245

Earlier quoted context omitted.

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

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

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.

Re: Omarchy: Any User Process Can Escalate to Root

#550

Post by kibbi »

mike_hearn wrote: post #513
mosura wrote: post #147

Earlier quoted context omitted.

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…

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