Live data from Hacker News

Memory-safe sudo to become the default in Ubuntu

trifectatech.org

71–80 of 282 posts

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

#71
post #66

Earlier quoted context omitted.

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.

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.

>I don't think you can realistically enforce a security boundary between root, and a user account that occasionally elevates.

So stop doing that!

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

#72

Earlier quoted context omitted.

This is a case of doubling down on bad design. To me it's wasted effort preventing theoretical bugs in niche setups.

I think the opposing view is that moving away from sudo is substantially more effort and would break basically everything to accomplish "the same" thing as robustifying sudo (for some very loose definition of "same")

Yes, it's more effort, but it's not close to being the same.

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

#73
post #40

Earlier quoted context omitted.

How is that any different than a daemon that has a parser error in its message handler, except that the daemon could be misconfigured to listen on a network socket? The original unix process abstraction was extremely simple; the entire spec is a few pages. The problem is that Linux keeps adding more and more levels of Rube Goldberg machine to its security model, so now literally no one understands how a default minim…

> How is that any different than a daemon that has a parser error in its message handler The non-daemon has to parse just as much in addition to making itself secure. Actually it needs to parse more things in more complex ways.

Assuming static linkage (which sudo has to assume), there’s really not much to parse. It should just be dealing with a null-delimited list (argv) and the caller’s environment variables (which it just needs to ignore and clear by default).

Here’s a simple implementation: https://github.com/TheMilkies/rut/blob/main/rut.c

(Though it doesn’t clear the environment unless I’m missing something - they should probably replace the call to execvp with one to execvpe, and add a null pointer to the end of the argument list).

The problem of setting up root’s environment and parsing the command line is left to the shell in both solutions (the thing I linked doesn’t indirect through a root login shell).

There’s also the config file, but that’s the same for both.

Similarly, the system could be running some SEL derivative or be using a capability system that causes non-standard behavior from system calls, but the daemon has the same problem.

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

#74

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.

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

#75
post #66

Earlier quoted context omitted.

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.

>I don't think you can realistically enforce a security boundary between root, and a user account that occasionally elevates. So stop doing that!

What should you do instead?

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

#76
post #46

Earlier quoted context omitted.

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

What kind of free pass would you want to give to locally run software? Can't you already do anything you want to GPL code locally?

GPLv2 was fine. AGPL is fine.

V3 is incompatible with selling bootloader locked software stacks (pretty much all consumer hardware these days).

Concretely, I can’t do this local thing: Take GPLv3 software, build a board, link the software to vendor blob firmware (~ all current hardware requires this step), flash it to a ROM on the board and sell it to you with a copy of the GPLv3 software’s source code.

I can take the same vendor blob, add a TCP stack, and have your device shell into a copy of GPLv3 software with closed source modifications running in my data center.

This has massive negative consequences for users of GPLv3-reliant IoT crap and cloud services.

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

#77

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]

I mean, I don't necessarily use rust a lot and it's not even possible to "use" in most cases in my domain (machine learning engineering)... But to say that it's religious is just weird. It would have been super easy to portray as religious every push for better engineering practices in other fields, in fact I bet that it would've happened if the internet was common back when people were doing exactly that for say, civil engineering or mechanical engineering.

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

#79
post #66

Earlier quoted context omitted.

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.

>I don't think you can realistically enforce a security boundary between root, and a user account that occasionally elevates. So stop doing that!

Who are you shouting at?

Going back to the topic of the discussion, making sudo more resilient prevents a whole class of possible bugs (see CVE-2021-3156). You may not like sudo, but it is very commonly used to manage access, prevent accidental errors, or improve accountability on Linux servers and workstations. It is not going away. Therefore, improving sudo is a worthwhile goal and a thing to be celebrated.

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

#80
post #78

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

Maybe "deployed" is the key word here. Android is treated like a fixture of mobile devices rather than a fungible Linux distro.
Post reply on HN