Memory-safe sudo to become the default in Ubuntu
66 comments
·May 6, 2025kokada
MajesticHobo2
Right, but now the vector for privilege escalation will have to be a logic bug in memory-safe sudo instead of either a memory corruption (see CVE-2021-3156) or a logic bug. It’s hard not to see this as a major improvement.
charcircuit
Being a setuid binary means that sudo also suffers from attacks where an attacker runs `sudo ./malware` and then convinces the user to authenticate. Depending on how sudo authenticates phishing attacks or password reuse from another breach can be used to escalate privileges.
jvanderbot
Those will also have to be fixed/considered, but do not detract from the contribution of removing memory safety bugs which may enable exploits.
im3w1l
I don't think you can realistically enforce a security boundary between root, and a user account that occasionally elevates.
You can enforce a boundary between root and an account that never elevates though. And as far as I understand hardening sudo helps with that.
Retr0id
A bug in a daemon-based sudo alternative would surely also result in privilege escalation?
I think the main benefit of eliminating setuid binaries is that you can forbid them system-wide (e.g. via mount flags), as a hardening measure.
JoshTriplett
There's value in always starting processes from a known-secure environment rather than attempting to transform a user's arbitrary environment into a secure one.
Retr0id
True, CVE-2021-4034 comes to mind as a recent example (exploiting zero-length argv)
null
ndegruchy
Seems like the trifecta group is /just/ about migrating tools to rust? Am I understanding that right?
I don't have a problem with it, specifically. Seems odd that they don't advertise it, though.
fossuser
The religious element of rust programmers seems more extreme than other languages. There’s always a little bit of that sort of thing, but rust programmers seem to have mixed theirs with politics too.
It makes me wonder how much is motivated by stuff other than what’s actually the best outcome.
tialaramex
Politics is just everything. "No politics" usually means, "Opinions which conflict with mine are unwelcome" or at best the small-C conservative idea that the status quo has existed forever and so whatever happens to presently be the case is just how things should be.
In your own comment you mention "actually the best outcome" but that's a matter of politics, doubtless you have different ideas about what "best" would be than I do, and I appreciate that perhaps you've never considered that anybody other than you could be right, but you might want to take a moment to think again.
jvanderbot
You've always encountered this, it just not (until recently) had a _whole language_ to migrate to. It's this strong impulse to do things the "right way" which is a very good instinct, but always has the danger of becoming "rigor theater". It's the same any time anyone proposes to "just" port to a new framework, or runtime, or platform, or language.
Tale as old as time.
mid-kid
We've accepted it at this point, but I wonder if the religious element of GNU tools and free software in general was as contentious way back when.
hedora
GNU sort of lost its way around GPLv3 (it gives cloud services a free pass, but not locally run software, which is the opposite of letting users control what their computer does).
That killed most of the “user freedom” enthusiasm of the early days. These days, there’s the AGPL, but that’s mostly used like the BSL (“if you want to use AGPL in production, pay us”), than for bootstrapping freedom-respecting compute environments.
If you disagree, show me an AGPL userland that’s appropriate for daily-driving.
I’m slowly migrating off Linux to the BSDs these days. The politics seem less destructive to the user experience with them.
Analemma_
A little while ago I realized with a start that it's been years since I've heard anyone angrily insist on calling it "GNU/Linux", when that was constant background noise during the Slashdot era. One of those old fights that just faded away, I guess.
nailer
It's not religious. Memory safety is a thing. If by politics you mean the government: they only got started recommending memory safe languages once it became clear that foreign actors were going to keep exploiting C / C++ vulnerabilities.
https://www.theregister.com/2024/11/08/the_us_government_wan...
CooCooCaCha
Is there actual substance behind this comment or are you against it because of emotional/political reasons?
dismalaf
Not like GNU is any less religious...
I think they just want to ditch GNU tools and lots of young, low level programmers want to use Rust (same rationale for Linus accepting Rust code into the kernel).
VWWHFSfQ
Memory safety is strictly a good thing, regardless of motivations.
But I'm aware that some people are frightened of new languages and paradigms especially if they're 'harder' than what they're used to.
davrosthedalek
Only if you don't buy any downsides with it. That makes it situational dependent. For example: - less people being able to read the code, work with the code, find (security) bugs - slower I know, I know, rust is not really slower, and for sudo it probably wouldn't even matter. But safety isn't the be all and end all of software. There is a lot of software out there where memory safety doesn't matter, or matters a lot less than other aspects.
Ygg2
> The religious element of rust programmers
Yeah. I too, hate the Rust Evangelically Orthodox Later Day Christians.
Oh, wait... You're serious. What is religious about rewriting tools in Rust? Isn't that what most programmers do for fun and learning?
Is it any more religious than worshiping Alan Kay or Dijkstra?
> It makes me wonder how much is motivated by stuff other than what’s actually the best outcome.
Looks in the thread... Sees https://www.sudo.ws/security/advisories/
Are you sure the status quo is the better outcome?
ziddoap
>What is religious about rewriting tools in Rust?
"Religious" isn't being used to refer to people rewriting tools in Rust.
It's used to refer to people zealously commenting on message boards that every single tool ever built should be rewritten in Rust, and if you aren't rewriting your tool in Rust, you're an idiot.
kjrfghslkdjfl
[dead]
john-h-k
The other big thing iirc is they’re all MIT licensed rather than GPL(et variants) licensed
ndiddy
Sudo is permissively licensed. https://www.sudo.ws/about/license/
bpierre
How does sudo-rs compare to run0? https://news.ycombinator.com/item?id=40205714
paulddraper
A trivial Google search answers that. run0 requires systemd-type OS.
ranger207
Given that Ubuntu uses systemd like the vast majority of Linux systems nowadays, how does sudo-rs differ from run0?
fweimer
You might not have a systemd instance inside a container, but you still might want to switch user IDs there.
hedora
sudo-rs doesn’t gratuitously require a root privilege daemon that regularly ships filesystem destruction and remote unauthenticated arbitrary code execution bugs.
If your bar is “I’ll tolerate such crap”, you may as well run your desktop session as root.
Rotundo
Did sudo have memory problems? Did it ever fail because it didn't handle its memory correctly?
mid-kid
There's been cases[1], of particular note, the unescape overflow one[2]. This one scathed the reputation of sudo enough to get people pushing for alternatives such as doas. The track record of vulnerabilities in general leaves a bit to be desired, even outside of memory vulns.
[1]: https://www.sudo.ws/security/advisories/
[2]: https://www.sudo.ws/security/advisories/unescape_overflow/
stop50
Sudo had quite a few problems with security, partially because of this doas was developed for BSD. Some problems come from the huge amount of features(ldap, easter eggs, ...). sudo-rs reduces the problems by not implementing those features.
ch_123
> Some problems come from the huge amount of features(ldap, easter eggs, ...). sudo-rs reduces the problems by not implementing those features.
This makes me wonder:
1) Would a hypothetical "sudo-lite" with these features removed lead to better security without a rewrite?
2) If these features are useful in the real world, will a Rust rewrite of sudo inevitably gain these features over time and end up with similar problems?
throw0101a
> 1) Would a hypothetical "sudo-lite" with these features removed lead to better security without a rewrite?
OpenBSD did this with their doas utility:
literalAardvark
It can't end up with similar problems, due to the memory safety guarantee.
That's not to say that it won't create other ones.
XorNot
Removing LDAP is a huge problem for the more important sudo deployments though: centralized management of permissions is kind of a vital function.
JoshTriplett
Debian is currently in the process of dropping the direct LDAP support in sudo, in favor of sssd. From sudo's NEWS.Debian.gz:
> In practice, there are few installations that use sudo-ldap. Most installations that use LDAP as a directory service and sudo have now opted for sssd, sssd-ldap and libsss-sudo.
> The Debian sudo team recommends the use of libsss-sudo for new installations and the migration of existing installations from sudo-ldap to libsss-sudo and sssd.
fluidcruft
Is it actually removing ldap or is it offloading to pam?
Filligree
Those people can keep using sudo; it’s not going away. The rest of us get better security.
dec0dedab0de
Could you clarify what you mean by more important sudo deployments?
dev_l1x_be
doas is a much simpler (and therefore better) alternative.
JoshTriplett
doas is not a compatible drop-in replacement for existing users.
dev_l1x_be
I did not claim that.
Here is my doas config:
cat /etc/doas.conf
permit nopass jane as root
Sudo: #ALL ALL = (root) NOPASSWD: C_ZFS
I have no idea what is going here, not sure what ALL means, why root is in (), etc.
778464636
Neither is sudo-rs. From TFA:
> some features of the original sudo will not be implemented in sudo-rs if they serve only highly niche use cases
hedora
I wonder if there’s one that hardcodes a simple policy like “members of the wheel group can run any command with a password, and a 5 minute timeout”, but is also sudo command line compatible.
That’s what 99% of distros default to, and it’s simple.
asmodeuslucifer
That's good to hear.
I am not sure if memory-safety is the biggest issue in sudo design. I find the fact that it is a setuid binary a much bigger issue because a bug can possible result in privilege escalation.
I found an alternative implementation that doesn't rely in being a setuid binary like systemd-run0 much more interesting from a security perspective, but I am no security expert.