[codetrotter]

> the doas comparison doesn’t really follow

The real question is, do you really need everything that sudo can do? Or would doas be sufficient?

On my FreeBSD servers, I install doas instead of sudo, and I have never once found myself missing any features in spite of having completely replaced sudo with doas on my FreeBSD servers.

Replaced as in, I no longer even have sudo installed on my FreeBSD servers. I switched from sudo to doas cold turkey years ago and haven’t looked back.

(On Linux I still use sudo, but that is simply because it comes pre-installed on the Linux distros I use so I haven’t bothered to install doas instead there.)

doas does exactly what I need; run the following command as root.

[eep_social]

Right, I’d speculate that removing sudo for doas is a heavy but feasible lift at the distro level. But as I said elsethread, I’m also very interested in an as-safe-as-possible replacement between now and then. Removing the need entirely (as they are both conceptually broken) seems like a huge lift that’s probably not feasible without fundamental changes. Could it be done within POSIX? IDK but I’d guess not.

[cedws]

>Removing the need entirely (as they are both conceptually broken) seems like a huge lift that’s probably not feasible without fundamental changes

A sort of workaround is that you can log in as the desired user from a TTY. Of course, this gets tricky if you don't have physical access or a remote serial connection. And you probably wouldn't want to log in as root over SSH. I don't have real solutions in mind but it's ticking over in my head. Might have some ideas later on.

[eep_social]

Aye, but then we are (I think) sharing credentials so we can both log in as the user with specific (read: elevated) permissions, and we lose any ability to know who the “real” person-user is on top. So it’s a different problem and we’re starting to talk about threat models and such..

[cedws]

> we lose any ability to know who the “real” person-user is on top

It's a complex topic probably best suited for discussion elsewhere, but do we even need to discern that anymore? Statistically most Linux systems running now are single-seat (as in, one real user).

A big corp with thousands of servers and employees might want to know this stuff for audit logging, but if employees have root access, they can already fake everything at ring 3. Big corps use security software that do that stuff in ring 0.

[e12e]

> if employees have root access

The main usecase of sudo over su (or suid binaries) is limited access (clear/re-run the mail queue - not reconfigure the mail daemon)

[yjftsjthsd-h]

> Right, I’d speculate that removing sudo for doas is a heavy but feasible lift at the distro level.

Not that heavy a lift, at least as a default. AIUI Alpine switched to doas and moved sudo to the community repo, Arch supports both, Void supports both, and NixOS supports both. I wouldn't be surprised if there are more. Although, RHEL and SUSE would probably have a harder time because their customers are more likely to use sudo's long tail of features.

[eep_social]

I’m only vaguely aware of Alpine but that’s pretty neat!

[e12e]

Users and groups (auth/autz) via kerberos/ldap/active directory? Radius?

Not something "most users" would need - and probably handled in Pam, not sudo - but it's one thing that comes to mind.

[inferiorhuman]

On FreeBSD the only thing I miss from sudo is the credential caching. I believe opendoas uses the same fairly portable method that sudo does. doas uses an OpenBSD-specific API.