181–190 of 260 posts
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.
OpenBSD is mainly used by hobbyists and not sysadmins, which is why there are not complaints about the missing functionality.
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…
Earlier quoted context omitted.
Sounds like a bit of recipe for accidentally handing access to an unintended privileged fd through inheritance (ignoring the /dev/fd one) such that a compromised unprivileged SUDO_EDITOR value gives you sudo access. Maybe not likely, but I’d really be hesitant about any feature that relies on implicit fd inheritance…
Close all other fds between fork and exec then (you can look at the code of base::LaunchProcess in Chromium for an example). It’s a minuscule amount of code to audit compared to XDG portals. And it’s backwards-compatible with decades of unix programs. For a more complicated solution: spawn a zygote process early with a unix socket which you’ll use to send the fd later. Zygote at start drops provileges. When it receiv…
There is the CLOEXEC flag which is the intended way to manage this but it’s not the default and you have to be diligent about setting it which again carries its own set of challenges.
What you’d really want is CLOEXEC implicitly on all fds and having to explicitly opt in for fd inheritance.
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…
Earlier quoted context omitted.
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.
This gets said a lot, but I am coming to believe that the case is overstated. For two reasons: 1. Valgrind exists. It's not perfect, but it does arguably do a pretty good job as long as you're writing modern C. The biggest gap I'm aware of is that it can't really help you with global pre-allocated buffers. But I don't think that any language or tool can effectively protect you from information leakage if you're doing…
There is no excuse to not at least have bounds checking. This is one of the most basic memory safety problems and it's trivial to prevent.
Just preventing this small issue will prevent a non-trivial fraction of bugs. I don't have sudo's bug list on hand but I wouldn't be surprised if 25% or more are caused by buffer overflows.
So even if it doesn't prevent all logic bugs, it cuts out a pretty big chunk of the bug list.
>assuming you don't switch them off
You can't switch them off.
>Rust community's tendency to pitch this stuff as a security panacea
I've not seen anyone claim this so far.
IIRC, all the recent sudo vulns are logic errors, not memory safety. I mean, rewrite away but let's not pretend that there couldn't be some new bug introduced due to a misunderstanding of how something works or just a plain old mistake.
> let's not pretend that there couldn't be some new bug introduced due to a misunderstanding of how something works or just a plain old mistake. Is anyone doing that? I see a lot of claims of memory safety, but as far as I can see the project isn’t saying other types of bugs are for sure eliminated.
Earlier quoted context omitted.
One of those left out features is `sudoedit` or `sudo -e`. I use this a lot when editing files in /etc or any file that my user does not have permissions. The flag first copies the file to a temporary location with permissions for my user to edit, then opens my text editor (defined via $SUDO_EDITOR env var) as _my user_, without any sudo permissions. After I close the editor, the file is copied back with the original…
This would be a great use case for a capability security model. Essentially what you really want is the sudo command to acquire a temporary capability token to edit that specific file. Then run your editor and pass it the capability. (And revoke the capability when the editor process closes). It’s a pity this isn’t more straight forward to implement on Linux.
Earlier quoted context omitted.
The link you cite says it was worse in the Rust version: > During the audit, it came to light that the original sudo implementation was also affected by [CLN-001: relative path traversal vulnerability], although with a lower security severity due to their use of the openat function.
Thank you. I literally re-read it to try and find this, and missed it somehow. Guess I need to drink even more coffee.
Have you tried green tea? It contains a substance that offsets the sideeffects of caffeine a little.
https://en.wikipedia.org/wiki/Theanine?wprov=sfla1
Disclaimer: Zero Caffeine for me either way. Makes my ADD way worse. Theanine was nice though. Okay i lied, i allow myself dark chocolate sometimes.
Earlier quoted context omitted.
Close all other fds between fork and exec then (you can look at the code of base::LaunchProcess in Chromium for an example). It’s a minuscule amount of code to audit compared to XDG portals. And it’s backwards-compatible with decades of unix programs. For a more complicated solution: spawn a zygote process early with a unix socket which you’ll use to send the fd later. Zygote at start drops provileges. When it receiv…
I’m not saying it’s not possible to do correctly. But do you not agree that the first is hard to correctly (can overlook an fd) while the latter is a lot of complexity? There is the CLOEXEC flag which is the intended way to manage this but it’s not the default and you have to be diligent about setting it which again carries its own set of challenges. What you’d really want is CLOEXEC implicitly on all fds and having…
Earlier quoted context omitted.
Perhaps, but if the goal is security of a critical tool, losing some attack surface (features) if they aren’t widely used is a win. Other projects, like ntpsec[0] have taken this approach with good results. Although, I agree with another commenter in this thread[1] that this effort would have been better directed at something with an inherently small attack surface like doas. 0 - https://www.ntpsec.org/accomplishment…
The features they are leaving out were presumably added for a reason. If someone is on a system that is using sudo-rs as a drop-in replacement (not under their control) and they need to use one of those less widely-used features, how secure is the work-around they have to use instead? I'm hoping this factored in to their analysis. Sometimes reimplementing something and leaving out lesser-used features to "reduce the…