[q3k]

You don't need a kernel LPE to root a Linux developer machine.

Just alias sudo to sudo-but-also-keep-password-and-execute-a-payload in ~/.bashrc and wait up to 24 hours. Maybe also simulate some breakage by intercepting other commands and force the user to run 'sudo systemctl' or something sooner rather than later.

[himata4113]

this, this is something I don't understand there are a billion ways to gain root once you control the user that regulary uses sudo.

this is only scary for rootless containers as it skips an isolation layer, but we've started shipping distroless containers which are not vulnerable to this due to the fact that they lack priviledge escalation commands such as su or sudo.

never trust software to begin with, sandbox everything you can and don't run it on your machine to begin with if possible.

[LeCompteSftware]

I agree that de facto the biggest security flaw in Linux is "okay I'm tired of getting interrupted all day assisting you, I know you're competent, I'll put you on the sudoers list."

But there are a lot of academic and research institutions that actually do have good Linux user management. I worked at a pediatric hospital, and the RHEL HPC admins did not mess around in terms of who was allowed to access which patients' data. As someone who was not an admin, it was a huge pain and it should have been. So this bug has pretty serious implications, seems like anyone at that hospital can abscond with a lot of deidentified data. [research HPC not as sensitive as the clinical stuff, which I think was all Windows Server]

[himata4113]

I think we've concluded already that user isolation is not safe and shouldn't be trusted, that's why we've invested to hard into namespacing(containers). users should only have what they need if you really care about security and don't want to tolerate the overhead of virtualization based security.

[BobbyTables2]

I doubt your “distroless” container is any safer for this vulnerability .

Infecting sudo just makes for a quick demo.

If your container has different processes at different user ids, the exploit would still be effective.

It would likely also be able to “modify” read only files mapped from the host.

[himata4113]

distroless rootless containers don't have the syscalls enabled to do anything reasonable with this exploit

[1718627440]

First, if you control the account of the administrator, you already have a worst case scenario. Second, this is why distros tell you to not use sudo. The purpose of sudo is to give some people the ability to run a very specific program with elevated privileges that wouldn't be allowed otherwise, while you don't want them to have any other administrative rights. If you want someone to be an admin over the system, just give them the root password.

[TacticalCoder]

> this, this is something I don't understand there are a billion ways to gain root once you control the user that regulary uses sudo.

I won't enter into all the details but... It's totally possible to not have the sudo command (or similar) on a system at all and to have su with the setuid bit off.

On my main desktop there's no sudo command there are zero binaries with the setuid bit set.

The only way to get root involves an "out-of-band" access, from another computer, that is not on the regular network [1].

This setup as worked for me since years. And years. And I very rarely need to be root on my desktop. When I do, I just use my out-of-band connection (from a tiny laptop whose only purpose is to perform root operations on my desktop).

For example today: I logged in as root blocked the three modules with the "dirty page" mitigation suggested by the person who reported the exploit.

You're not faking sudo with a mocking-bird on my machine. You're not using "su" from a regular user account. No userns either (no "insmod", no nothing).

Note that it's still possible to have several non-root users logged in as once: but from one user account, you cannot log in as another. You can however switch to TTY2, TTY3, etc. and log in as another user. And the whole XKCD about "get local account, get everything of importance", ain't valid either in my case.

I'm not saying it's perfect but it's not as simple as "get a local shell, wait until user enters 'sudo', get root". No sudo, no su.

It's brutally simple.

And, the best of all, it's a fully usable desktop: I'm using such a setup since years (I've also got servers, including at home, with Proxmox and VMs etc., but that's another topic).

[theamk]

Do you install system-wide software at all? How do you configure it?

That's my main reason to use "sudo" on the desktop.

I suppose I could install every piece of software locally, either from source or via flatpak, but this is a lot of work and much harder than doing it the easy way and using global install via my distro. Plus, non-distro installs are much more likely to be out of date and contain vulnerabilities of their own.

[himata4113]

nixos comes to mind, rootless runpod, qubesos.

but they all have something in common, the issue is that your user is compromised that means the applications running in that user are compromised the only thing you gain is that you can trust your system, you can trust that your system is not compromised which is only relevant with infrastructure since if your user is compromised you're already fucked, multi-user setups with untrusted accounts are inheritly insecure and in infrastrucure the blast radius might be thousands of users that use the said service.

the breakdown looks something like this:

  - you heavily compromise a single user <- exploit not relevant
  - you compromise a shared setup via a bad user to compromise a lot of users <- should never be used anymore, namespace isolation is the replacement
  - you somewhat compromise a lot of users via infra compromise <- where this hurts

[q3k]

Yes, you are very special and smart. Good for you!

Most people however aren't and will happily run sudo after an npm postinstall script tells them to apt-install turboencabulator for their new frontend framework to function.

[1718627440]

You really can't protect against a malicious sysadmin. Let them be bitten, maybe they will be smarter next time.

[FrinkleFrankle]

Would you mind sharing the relevant config?

[cozzyd]

right, a bigger issue is multitenant systems, which are common in academia (I manage several such systems for various experiments). Now, we generally trust the users to not be malicious, but most don't get sudo, because physicists tend to think they know what they're doing when they don't really (except for me, of course).

Something that concerns me more is I use things like gemini-cli or claude-cli via their own, non-sudo accounts with no ssh keys or anything on my laptop, but a LPE means they can find away around such restrictions if they feel like it (and they might).

[1718627440]

When you control the bashrc of some other person, it is already kind of game over.

[krupan]

That's why I only do passwordless sudo ;)

Actually now I use my yubikey to authentice so I don't have to type my password for sudo. Take that!

[Terr_]

Perhaps, but it makes a huge difference if you're running the vulnerable code in a container or as a different user.