Memory-safe sudo to become the default in Ubuntu
trifectatech.org
Memory-safe sudo to become the default in Ubuntu
1–10 of 282 posts
Re: Memory-safe sudo to become the default in Ubuntu
#2Did sudo have memory problems? Did it ever fail because it didn't handle its memory correctly?
Re: Memory-safe sudo to become the default in Ubuntu
#3Did sudo have memory problems? Did it ever fail because it didn't handle its memory correctly?
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.
Re: Memory-safe sudo to become the default in Ubuntu
#4Did sudo have memory problems? Did it ever fail because it didn't handle its memory correctly?
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/
Re: Memory-safe sudo to become the default in Ubuntu
#5Did sudo have memory problems? Did it ever fail because it didn't handle its memory correctly?
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.
Removing LDAP is a huge problem for the more important sudo deployments though: centralized management of permissions is kind of a vital function.
Re: Memory-safe sudo to become the default in Ubuntu
#6Seems 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.
Re: Memory-safe sudo to become the default in Ubuntu
#7Earlier quoted context omitted.
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.
Removing LDAP is a huge problem for the more important sudo deployments though: centralized management of permissions is kind of a vital function.
Those people can keep using sudo; it’s not going away. The rest of us get better security.
Re: Memory-safe sudo to become the default in Ubuntu
#8Did sudo have memory problems? Did it ever fail because it didn't handle its memory correctly?
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.
> 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?
Re: Memory-safe sudo to become the default in Ubuntu
#9Earlier quoted context omitted.
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.
Removing LDAP is a huge problem for the more important sudo deployments though: centralized management of permissions is kind of a vital function.
Is it actually removing ldap or is it offloading to pam?
Re: Memory-safe sudo to become the default in Ubuntu
#10I 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.