Live data from Hacker News

Memory-safe sudo to become the default in Ubuntu

trifectatech.org

231–240 of 282 posts

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

#231

Earlier quoted context omitted.

Well yeah you can't enforce any security boundary if your threat model includes "user might be tricked". It can't be enforced on Linux because `sudo` can be trivially MitM'd, but you can't do that on Windows because it's just a click.

But the entire threat model we were discussing was that the user might be tricked: Being a setuid binary means that sudo also suffers from attacks where an attacker runs `sudo ./malware` and then convinces the user to authenticate That's why the OP said that's not an enforceable security boundary. If the user is capable of attaining superuser privs, you can trick them, regardless of how attaining those privs is imple…

Yeah I wasn't agreeing with that either.

I didn't interpret OP's comment like that. I think he was saying you can't enforce the boundary at all even if users don't get tricked.

That's true on Linux because the sudo UI can trivially be MitM'd by malware. You can't do that on Windows so trivially.

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

#232

Earlier quoted context omitted.

So why are we not using Ada / SPARK?

Why does it matter, really? I mean sure, ada could've been an alternative language that everyone pushed for using but it kind of missed the boat due to historical circumstances , the context around its early use, etc. It might even be that rust users are just more enthusiastic and have been able to push more... But so what? But why does it matter if the language that has seen some traction in terms of "rewriting soft…

This sounds like a dismissal. It is worth getting rid of the misunderstandings of Ada. It is worth letting people know that safe alternatives to C do exist and have existed long before Rust. You said it yourself that the issue may have been historical circumstances, in which case it should be clarified. Ada has a lot of great things built-in to the language. I especially love its type system and constructs for concurrency. Imagine if it had the hype of Rust, as a better alternative to C (which it easily could be). It goes further than Rust when it comes to safety, there is a reason for why you can find it in critical software.

> But why does it matter if the language that has seen some traction in terms of "rewriting software in safer languages" is rust? At that point it becomes even more religious to just reflexively oppose rust because "well why didn't x or y see the same push??"? Again, it really doesn't matter why!

If it does not matter, then why not Ada / SPARK indeed? I am sure the whys matter to some extent.

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

#233

doas is a much simpler (and therefore better) alternative.

doas is a really bad option on Linux. The Linux port has not been maintained for 3 years. Has unmerged rowhammer fixes and generally a yolo auth system best described as "dangerous". You are better off using a well maintained project, that includes the CVEs^Wwarts. It's a mistake to think that `doas` on Linux is the same as `doas` on BSD.

We need a doas-rs port that is maintained, i guess.

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

#234
post #78

> Ubuntu is the most widely deployed Linux operating system Nitpicking, but I thought Android was the most widely deployed Linux OS around...

That's the logic Oracle uses to say Java is the most widely deployed language in the world, because it runs on phone sim cards and credit cards

I think that's alright?

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

#235
post #222

doas is a much simpler (and therefore better) alternative.

Both implementations of doas for Linux have (the same) unfixed security issue: - https://github.com/Duncaen/OpenDoas/issues/106 - https://github.com/slicer69/doas/issues/110 I have a hard time recommending doas over sudo on Linux when the issue has been fixed in sudo but not in doas.

Those should be closed WONTFIX. Neither doas nor sudo can protect you from the consequences of running untrusted code and must not attempt to do so because it adds needless complexity to safety-critical software.

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

#236

Earlier quoted context omitted.

doas is a really bad option on Linux. The Linux port has not been maintained for 3 years. Has unmerged rowhammer fixes and generally a yolo auth system best described as "dangerous". You are better off using a well maintained project, that includes the CVEs^Wwarts. It's a mistake to think that `doas` on Linux is the same as `doas` on BSD.

We need a doas-rs port that is maintained, i guess.

Just as with the sudo-rs reimplementation, a doas-rs rewrite is not going to solve the inherent issues we get with SUID binaries. We are better off implementing better models (see ssh and run0).

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

#237

Earlier quoted context omitted.

But the entire threat model we were discussing was that the user might be tricked: Being a setuid binary means that sudo also suffers from attacks where an attacker runs `sudo ./malware` and then convinces the user to authenticate That's why the OP said that's not an enforceable security boundary. If the user is capable of attaining superuser privs, you can trick them, regardless of how attaining those privs is imple…

Yeah I wasn't agreeing with that either. I didn't interpret OP's comment like that. I think he was saying you can't enforce the boundary at all even if users don't get tricked. That's true on Linux because the sudo UI can trivially be MitM'd by malware. You can't do that on Windows so trivially.

That was doable, and how it worked, under Windows until a few weeks ago [0].

[0] https://cyberdom.blog/abusing-the-windows-update-stack-to-ga...

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

#238

Earlier quoted context omitted.

For me it was their begging for money on install.

Would you prefer the Microsoft way of begging for money before install?

I prefer the Arch way of "begging for money on install", which is to say, none at all.

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

#239
post #183
post #121

> This move is part of a broader effort by Canonical to improve the resilience and maintainability of core system components. Sudo-rs is developed by the Trifecta Tech Foundation (TTF), a nonprofit organization that creates secure, open source building blocks for infrastructure software. Ubuntu continuously updates itself without permission, killing apps and losing previous state. You have the Javascript based Gnome…

> Ubuntu continuously updates itself without permission... It does default to installing security updates automatically. However, this is completely configurable. It isn't reasonable to have different default behaviour - otherwise the majority of users would be vulnerable from a security perspective. If you want different behaviour, just configure it as you wish. > The Ubuntu packages, drivers and kernel are laughabl…

> It does default to installing security updates automatically. However, this is completely configurable.

Man, but have you personally tried to disable it?

Did you stop apt-daily.service apt-daily.time apt-daily-upgrade.service and apt-daily.timer? Did you repeat the same but masking and disabling those services. Don't forget to repeat that for unatended-upgrades.service. Even after that whenever our CI fails an apt-get we have a pstree output to figure out what other dark pattern canonical came up with.

This whole debacle made me consider RedHat for my next install, and I use Ubuntu for almost 2 decades. It became unreliable in servers.

Dont get me started on the lack of security updates on "multiverse" packages which starts to include more and more packages and thus LTS means less and less. This is not innocent but so you buy Ubuntu One.

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

#240
post #206

Earlier quoted context omitted.

All the links are now fixed and return OK now. I don't think Whitehouse data archival is what the parent was referring to.

There were a lot of people online misinterpreting it, it’s possible they saw one of those threads.

I was one of those people indeed, and I appreciate your clarifications in this thread.
Post reply on HN