This is technically an interesting bug, but the implications are very minor. The only situation where this can be exploited is when you allow a user to execute something as any other users except root. This seems pretty obscure and probably affects only an extremely small number of configurations.
Pretty much all the headlines I saw on this were overstating or stretching the impact.
But I don't think this is a rare situation. For example you can allow a bunch of users to restart and change a buildbot infrastructure (which runs as its own user, not root).
Agreed it is not likely to hit many people in production, but the writeup on the oss-security post, linked to below is a fascinating reminder of deeply buried assumptions buried, that make security hard.
Does anybody actually have sudo access on a system that they don't also have 100% control over?
I feel like linux as a true multi-user system, especially to the level of having sudo access, is such a minority use case that I would never actually trust it in production.
In high performance computing, the supercomputing cluster is usually a shared Linux environment. Each user gets a home directory and groups are used for projects. As an intern working on one, they gave me limited sudo access to run a few commands but not everything (stuff like reading logs was fine but not able to power off the cluster).
You need sudo access (at least in Linux Mint, I suspect also in Ubuntu) to be able to manipulate printer settings. I've setup this for a special role granted to all users on our machines at home as sometimes the printers are recognized as offline although they are clearly online.
That is literally the stated purpose of sudo, and the source of its complexity. If you're happy with root access being all-or-nothing, 'su' is adequate. Polkit is another massively complex and ubiquitous system designed to address the same 'minority use case'.
Unpopular opinion: you're right, the vast majority of the time a workstation is single-user, in which case the whole mess isn't worth the hassle and one might as well only have a root account. Heresy! But I've never heard a plausible reasoning why it's fine for $BAD_THING to happen to my home directory, but not /. There's even an xkcd[0] to this effect, which means it must be true.
At least polkit is a policy engine that tries to enforce security based upon what you're doing rather than which command you run. Sudo is a broken design IMO, I only ever use it locally to run all root commands so I don't accidentally nuke an important system directory.
Polkit isn't great, but it's also been given the hard job of trying to retrofit policy based security to a system that was not designed with that in mind. But with sudo, so many commands in linux are such a swiss army knife of options that I think its incredibly easy to open up priviledge escalation by adding a seemingly innocent command to somebodies sudoers.
Pretty much all the headlines I saw on this were overstating or stretching the impact.
But I don't think this is a rare situation. For example you can allow a bunch of users to restart and change a buildbot infrastructure (which runs as its own user, not root).
I feel like linux as a true multi-user system, especially to the level of having sudo access, is such a minority use case that I would never actually trust it in production.
There are mundane use cases for this.
Unpopular opinion: you're right, the vast majority of the time a workstation is single-user, in which case the whole mess isn't worth the hassle and one might as well only have a root account. Heresy! But I've never heard a plausible reasoning why it's fine for $BAD_THING to happen to my home directory, but not /. There's even an xkcd[0] to this effect, which means it must be true.
Hell, for that matter:
echo "alias sudo='sudo evil_command; sudo'" >> ~/.bashrc
is a pretty practical privilege escalation attack for 99% of systems with sudo. I don't think it's worth it.
[0]https://xkcd.com/1200/
Polkit isn't great, but it's also been given the hard job of trying to retrofit policy based security to a system that was not designed with that in mind. But with sudo, so many commands in linux are such a swiss army knife of options that I think its incredibly easy to open up priviledge escalation by adding a seemingly innocent command to somebodies sudoers.