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.

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.

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.

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.

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.

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?

Just don't be in the sudo group.

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.

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.

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 ¯\_ (ツ)_/¯

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.

You basically don’t use sudo on macOS though. Maybe once in a blue moon

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.

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.