Live data from Hacker News

The first stable release of a memory safe sudo implementation

memorysafety.org

71–80 of 260 posts

Re: The first stable release of a memory safe sudo implementation

#71

Earlier quoted context omitted.

OpenBSD replaced sudo with doas (with a vastly reduced feature set) several years ago, and without breaking everything. Sure there are use cases where you absolutely need some feature of sudo, but you can always install it.

That seems like the Right Way to do it... As annoying as it is to have to update every sudo reference -> doas, it forces you to think about everywhere you're using it, rather than waiting to see what breaks and then trying to fix it.

> As annoying as it is to have to update every sudo reference -> doas, it forces you to think about everywhere you're using it, rather than waiting to see what breaks and then trying to fix it.

In my scripts I never call sudo or doas. Instead, if the script needs to do something as root, I write the whole script so that it expects to itself be run as root.

And then when I want to run my script, I run it as root

    doas ./somescript.zsh

Re: The first stable release of a memory safe sudo implementation

#72
post #60

As one of the original creators of sudo ( https://en.wikipedia.org/wiki/Sudo ) I've witnessed it getting nearly totally rewritten and then incrementally bug-fixed over the last 43 years. It must take the prize for the UNIX command most highly-scrutinized for security flaws. Flaws which have been identified and fixed. Thousands of developers and security experts have gone over it. So part of me wonders - how is it pos…

No, but maybe it feels better to know memory bugs aren't there (but all others are, and worse than in sudo)

Re: The first stable release of a memory safe sudo implementation

#73
post #60

As one of the original creators of sudo ( https://en.wikipedia.org/wiki/Sudo ) I've witnessed it getting nearly totally rewritten and then incrementally bug-fixed over the last 43 years. It must take the prize for the UNIX command most highly-scrutinized for security flaws. Flaws which have been identified and fixed. Thousands of developers and security experts have gone over it. So part of me wonders - how is it pos…

> Is there something to this Rust language which magically eliminates all chances of any bug being introduced?

no, altough it has features that prevent or reduce the probability of some types of bugs - one example of this being memory safety bugs. rust can't prevent logic bugs.

the rust reimplementation probably has more bugs than the original, but a theoretically better chance to achieve fewer bugs in the long run.

is rewriting mature linux infrastructure in rust a good idea? many people agree that no, it's probably not a good idea outside of special use cases.

Re: The first stable release of a memory safe sudo implementation

#74

Earlier quoted context omitted.

For sure! But that mistake has already been made, and has been in the wild for years, so removing those features (and proposing yourself as a replacement for the original) is now a breaking change

OpenBSD replaced sudo with doas (with a vastly reduced feature set) several years ago, and without breaking everything. Sure there are use cases where you absolutely need some feature of sudo, but you can always install it.

> without breaking everything

Except all exiting use of sudo ...

It's such an entrenched tool that I'm sure there a compatible replacement could be useful.

Personally I would appreciate someone to take on the mess that is PAM. It was much too complex from the start and it hasn't become better over the years.

Re: The first stable release of a memory safe sudo implementation

#75
post #67
post #60

As one of the original creators of sudo ( https://en.wikipedia.org/wiki/Sudo ) I've witnessed it getting nearly totally rewritten and then incrementally bug-fixed over the last 43 years. It must take the prize for the UNIX command most highly-scrutinized for security flaws. Flaws which have been identified and fixed. Thousands of developers and security experts have gone over it. So part of me wonders - how is it pos…

In memory safety ? Yes, the language is much better at being safe by default. But it does nothing for logics bugs. The thing is, replacing from C (sudo or anything else), the number of exploit due to null pointer or buffer abuse or ... represent easily 50% of it.

Is that because theyre easy to find, or because theyre the worst?

Re: The first stable release of a memory safe sudo implementation

#76

Earlier quoted context omitted.

For sure! But that mistake has already been made, and has been in the wild for years, so removing those features (and proposing yourself as a replacement for the original) is now a breaking change

OpenBSD replaced sudo with doas (with a vastly reduced feature set) several years ago, and without breaking everything. Sure there are use cases where you absolutely need some feature of sudo, but you can always install it.

OpenBSD is mainly used by hobbyists and not sysadmins, which is why there are not complaints about the missing functionality.

Re: The first stable release of a memory safe sudo implementation

#77

Earlier quoted context omitted.

That seems like the Right Way to do it... As annoying as it is to have to update every sudo reference -> doas, it forces you to think about everywhere you're using it, rather than waiting to see what breaks and then trying to fix it.

> As annoying as it is to have to update every sudo reference -> doas, it forces you to think about everywhere you're using it, rather than waiting to see what breaks and then trying to fix it. In my scripts I never call sudo or doas. Instead, if the script needs to do something as root, I write the whole script so that it expects to itself be run as root. And then when I want to run my script, I run it as root doas…

That's a much worse approach from a security pov.

Re: The first stable release of a memory safe sudo implementation

#78

Earlier quoted context omitted.

> As annoying as it is to have to update every sudo reference -> doas, it forces you to think about everywhere you're using it, rather than waiting to see what breaks and then trying to fix it. In my scripts I never call sudo or doas. Instead, if the script needs to do something as root, I write the whole script so that it expects to itself be run as root. And then when I want to run my script, I run it as root doas…

That's a much worse approach from a security pov.

No. That’s a blanket statement on your part that you cannot make because you don’t know what my scripts look like, or what commands they call.

Re: The first stable release of a memory safe sudo implementation

#79
post #62
post #29

Earlier quoted context omitted.

OpenBSD is much more open (pun not intended!) about breaking parts of userspace to push through beneficial changes. After all, they control their own userspace and can fix up most things before they even become an issue. Linux is only the kernel.

In that case, shouldn’t Linux distros be even more free to break things…? In theory they can bundle any userland tools they want. AFAIK sudo isn’t really tightly coupled to the kernel itself.

They could, but their users really won't like that. They have their workflows that they got used to. In practice it's gonna be GNU Coreutils and Glibc and the other usual suspects. If they bundle something more exotic, it better be for a very good reason. For example musl on Alpine or what Android does.

Re: The first stable release of a memory safe sudo implementation

#80
post #60

As one of the original creators of sudo ( https://en.wikipedia.org/wiki/Sudo ) I've witnessed it getting nearly totally rewritten and then incrementally bug-fixed over the last 43 years. It must take the prize for the UNIX command most highly-scrutinized for security flaws. Flaws which have been identified and fixed. Thousands of developers and security experts have gone over it. So part of me wonders - how is it pos…

I think a better question might be whether it prevents categories of bugs that are more likely to be exploitable than, say, the logic errors that no language could ever prevent?

Also, it sounds like your seasoned eyes would be valuable in reviewing this code.

Post reply on HN