doas

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.

OpenDOAS has actually had the OpenBSD-specific code removed (https://github.com/Duncaen/OpenDoas/commit/74449f015ff7a7230...), and replaces some of the doas mechanisms that rely upon OpenBSD to work with sudo-like flag files and suchlike. There are, moreover, 2 ports of doas to other systems. OpenDOAS is one. Jesse Smith's https://github.com/slicer69/doas is the other. The latter retains the OpenBSD-specific code, and is the more portable of the two at the expense of only doing everything that the tool is capable of when actually built on OpenBSD.

There are many unofficial efforts to bring OpenBSD software to other systems. For example, there are at least two maintained ports of OpenBSD ksh, https://github.com/dimkr/loksh (Linux) and https://github.com/ibara/oksh (cross-platform). There are also at least two of doas, https://github.com/slicer69/doas and https://github.com/nholstein/OpenDoas. I wish they were catalogued somewhere, like an "awesome list". I would love to see portable OpenBSD cron. Features like random ranges with steps (https://undeadly.org/cgi?action=article;sid=20230507122935) and `-s` (https://man.openbsd.org/OpenBSD-7.2/crontab.5#s) put it ahead of almost every other. It could replace many uses of systemd timers on Linux. Edit: Added doas ports.

There's also a straight port of doas: https://github.com/slicer69/doas/ However unlike sudo and opendoas this does not implement the persist feature on not-OpenBSD.

As mentioned elsewhere, this is because it relies upon a kernel mechanism that Linux simply does not have, and fixing this involves fixing Linux. To which I add that it is important not to conflate Jesse Smith's doas, the portable doas that has code for different operating systems including OpenBSD, with Duncan Overbruck's OpenDoas, the "open" doas that is tied to Linux has has had the code for other operating systems removed and mechanisms copied in from sudo for things like timeout flag files. * https://github.com/slicer69/doas * https://github.com/Duncaen/OpenDoas

TIOCSTI is irrelevant. When one is dropping privileges, in a system cron job or in a process supervised by one's favourite service management system, there is no terminal involved. TIOCSTI simply doesn't enter into the picture at all. Only when one is in a terminal login session and using su to elevate / add privileges, does TIOCSTI become relevant. But no-one here is saying not to use su to add privileges. People blame su, sudo, and (as the person at https://github.com/slicer69/doas/issues/110 did) doas for this feature of operating system kernels. The right thing to do with TIOCSTI it to just eliminate it from the kernel. OpenBSD did back in version 6. Sadly, the argument from Alan Cox, Linux developer, when this was proposed years ago was that it should stay in Linux, and all of the programs like su, sudo, and doas should have even

It's more likely that this is the entire "upstream downstream" development model in action again. There are vast numbers of improvements to softwares that never get sent to the places where they will do the most good (or at least have a proper record of why they were rejected by their authors). A quick perusal of the bug trackers of Debian or Ubuntu will reveal tonnes of local patches that the original authors of the softwares often never even hear about. Things don't "stick" often times simply because they get lost. I was looking at something like that just the other day. Here's a bug report that describes a problem with "doas" not opening the controlling terminal to do its authentication dialogue. This is actually a problem with a package named LinuxPAM, and doesn't occur when "doas" uses OpenPAM or BSD Auth. It's LinuxPAM that's wh

I would say that the concept and implementation in C is inherently insecure. Switching to something less reviewed because there is a sudo vulnerability is not a guarantee that you are now "safer" especially if those ports are not reviewed. As far as I can say, never ever use slicer69/doas, I've found 3 critical security vulnerabilities in it, the author does not understand C or how it should work in general. Here are 3 examples if issues I found and the author used misleading commit titles to hide the issues and made excuses saying a clear buffer overflow very similar to the one found in sudo is just "potential": - https://github.com/slicer69/doas/commit/261c2164496dbebe6e3e... - https://github.com/slicer69/doas/commit/2f83222829448e5bc4c9... I even had to do a PR myself to fix an issue the author was not able to understand and more and m

I've heard of doas sometimes and it's much simpler than sudo, but it's powerful. Doas has two non-official port for Linux[0][1], but it would be great if someone developed an official tool like doas for Linux. [0] https://github.com/multiplexd/doas [1] https://github.com/slicer69/doas

If backward compatibility is not required, then OpenBSD's doas[0] may be a suitable alternative. Someone[1]'s ported it to other UNIX-like systems, though I don't know how good the port is. [0] https://man.openbsd.org/doas [1] https://github.com/slicer69/doas