Live data from Hacker News

Memory-safe sudo to become the default in Ubuntu

trifectatech.org

11–20 of 282 posts

Re: Memory-safe sudo to become the default in Ubuntu

#12

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.

The other big thing iirc is they’re all MIT licensed rather than GPL(et variants) licensed

Re: Memory-safe sudo to become the default in Ubuntu

#13
post #8
post #3

Earlier 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.

> 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 pro…

> 1) Would a hypothetical "sudo-lite" with these features removed lead to better security without a rewrite?

OpenBSD did this with their doas utility:

* https://en.wikipedia.org/wiki/Doas

Re: Memory-safe sudo to become the default in Ubuntu

#14
post #10

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.

[deleted]

Re: Memory-safe sudo to become the default in Ubuntu

#15
post #10

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.

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.

Re: Memory-safe sudo to become the default in Ubuntu

#16
post #10

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.

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.

Re: Memory-safe sudo to become the default in Ubuntu

#18

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.

[flagged]

> 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?

Re: Memory-safe sudo to become the default in Ubuntu

#20
post #15
post #10

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.

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.

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.
Post reply on HN