Sudo Usage
This is a direct response to: https://dotat.at/@/2024-05-02-sudo.html
- Because you should not log in to root directly.
- is the key point I think that needs rebutting
- As a safety guard.
- this is basically an argument for really or doas and not sudo - and I mostly agree with that
- For auditing.
- the core of this one seems to be the author being unable to read logs, which is fine and their prerogative, and I know LOTS of orgs that can't read logs
- It's a general-purpose tool.
- this is a weird one - because I don't really understand the larger argument - aren't they all just bloated su -c? but it contains a bunch of juice I think the author isn't engaging with
- For single-user workstations.
- This is an argument for a simpiler tool which I mostly agree with.
Alright - let's actually tackle these.
Because you should not log in to root directly.
So I think that, for the most part, this is motivated by something reasonable, with a bunch of fairly bad ideas inside it.
Not logging in directly as root allows the user to be contained within a context, and allows you to write proper guard rails trivially around that user. I understand that this is written for the context of operations staff for the most part, and so let's stay on that side of it.
Operations staff on a server which can be referred to as "cattle" (servers that are fungible) probably could login as root, but then why aren't you just replacing the server if you login? Whereas if you have long running production servers, making mistakes is critical and possibly hours or days of downtime. This is a terrible idea, and rejecting one layer of defense because you have other options is just a failure of imagination.
On a personal note - having a bunch of my ansible scripts not be allowed to be root is very nice. If something changes and a non-root user can't do something suddenly, I'd like to have that surprise. I much prefer my surprises to happen when I'm looking at them.
As a safety guard
This is a confusing statement. Not having defense in depth is good! All of the proposed solutions are non-technical - actual mistakes can still happen, but intentional mistakes will be harder. If someone types rm -rf /home /username/src, something that happens if you copy/paste wrong - having the terminal being a different colour wont fix it, and you've still lost /home.
I will often run commands first as not-root, see what errors I get (and if they're the ones I expect), and then attach a sudo (though on my personal systems sudo is aliased to doas, I just don't want to lose the muscle memory on shared systems) (this is also a good point, because if I am running as the user root, I lose that alias, and that sucks, I like my login context!).
It's a general-purpose tool
I don't understand this specific argument. I guess that from the author's perspective people argue for sudo due to its features, and I guess I understand that. I will very often build setups where users can run a very small set of commands. When I was a new unix admin, I was given the tools to restart the webserver, fix some DNS stuff, add aliases to the mail server, and restart its daemons. But nothing dangerous. These tools exist for a reason and are good. Not having tools for partial admin of a server is bonkers. This is why doas supports this.
Sure, if you're an effectively root user you might want a lighter tool - but why memorize two!
For auditing
Yeah, ok, so not being in shops where people are properly using logs is a bad thing. Be the logs-obsessed-sysadmin you want to see in the world.
But no, the author is correct! A good system will log no matter which one it is, it's not a good argument for sudo!
For single-user workstations.
This is another one of those things where they're single source arguing against sudo which I agree with.
Final Thoughts
I am 100% on board with this "don't use sudo" thing, with the obvious context that the article was written in. I am a fan of doas personally, and the other seems a fan of really (which seem a fine tool). This article was also written in the shadow of systemd's run0 and that context can't be removed.
I personally think we shouldn't have standards here! I think we shouldn't login to systems as root whenever possible! Having users have their own user context has real value, and having users fucking up because they didn't realize something had changed and were root is bad. Root can't be limited. You can't say "don't fuck with this file without a good reason" to root. And that's good. And that's what root is for, and having a tool to allow escalation has value.
The problem that this author seems to be raising is that sudo is too big and bloated, too large, and too complex, and a smaller tool is valuable. But this is the core of the problem of bloated tooling. Tools grow, organically. Sudo has had so much to do, so many resources, so many options, and that's why its bloated. If we'd chosen another tool, it likely would also be bloated.
Replacing sudo with a smaller tool would likely lead to that tool growing to the side of sudo. Run0 as far as I am aware is a version of sudo with less expressiveness but more dependencies and doesn't work on the vast majority of systems. Really is limited in what it can do and the ways that your system can be configured. Therefore those are limited purpose versions of tools that do the task that sudo and doas both do well, and I think having more tools is better than fewer tools, at least if we want a functioning ecosystem.
