
Is Sudo Almost Useless? - arshbot
https://security.stackexchange.com/questions/232924/is-sudo-almost-useless
======
mywittyname
Do people work under the assumption that sudo is meant to protect against
malicious actors? I always considered it an administrative tool to
differentiate between authorized users and administrators. You can, for
example, limit a user to only running `sudo service` so they can log in an
restart a service, but not make any other changes.

I thought the general strategy was to not give daemon accounts shell access at
all. Getting shell access is the hard part for a malicious actor. Once you
have shell, root access is just a matter of finding a piece of unpatched
software with a privilege escalation exploit out there. Plus, there's still a
lot of damage you can do without root access.

~~~
parliament32
>Plus, there's still a lot of damage you can do without root access.

That's not really true. An unprivileged user shouldn't be able to take down a
production system, or really adversely effect other users. Assuming you have
disk quotas enabled, what else could an unprivileged user do?

~~~
mywittyname
My line of thinking was theft or data modification.

I have access to this box and it has granted me access to some other system
which has useful data, like a database, NFS mount, or S3 bucket. Let me hop in
here and grep for something juicy to steal, maybe flip some bits around to
fuck with people, or just delete shit.

~~~
dependenttypes
> theft

You can't steal data unless if you intentionally delete the original after
copying, but then that is not really theft as any proper organisation will
have backups.

~~~
mc32
So someone steals a book from a library isn’t theft because they have
secondary copies?

~~~
0_gravitas
A better analogy would be photocopying all the contents of one of the books
and putting it back on the shelf

------
karatestomp
> The only purpose of sudo is to protect you from yourself, that is, to avoid
> messing up your system by mistake.

This is one reason I increasingly don't like the normal Linux distro "system
packages, _plus_ everything else under the sun, with one interface and all co-
mingled" default package management solution. I big fat "update the system"
(or don't) button with my user-installed packages totally separate, as I get
with macOS, is nicer. This made worse because, unless you're self-managing the
base system and keeping it super minimal (as one might in Gentoo, Arch, or
Void) Linux installations are weirdly fragile, I think in part because of this
too-large package ecosystem all tied up with the "core" of the OS.

Especially on a single-user system, I should be able to install most software
without escalating privileges. I should be able to blanket-update my user-
facing software without any risk whatsoever that a kernel update will get
thrown in with that (even if I don't read over the list to check—it shouldn't
even be possible), nor with privileges to perform such even if it somehow did
try to sneak in. I ought to be able to delete the directory with my user-
installed packages and the system still boots with no errors or warnings—and
yes, with a GUI and audio and networking and all that still working.

I know Nix and even a Homebrew port (with worse package availability, though)
are options for achieving something kinda like this but it still feels like
swimming against the current.

~~~
elagost
"user-installed packages totally separate" from the system is more or less how
the BSDs work. OpenBSD provides user packages via pkg_add and pkg_delete, and
the system updates with syspatch/sysupgrade. FreeBSD uses pkg update/pkg
upgrade for user-installed packages, and freebsd-update for system updates.
Maybe you'd like those systems better.

~~~
karatestomp
Yeah, I'm thinking about trialing FreeBSD for both that and having better man
pages (Linux's are _so_ incredibly bad). OpenBSD seems even nicer but I also
like having, you know, software and drivers that Just Work™, which already
seems like it might be a problem on FreeBSD. I haven't _enjoyed_ using desktop
Linux since like 2008 (it is _not_ a coincidence that this is about when
Poettering started to influence major distros with his NIH-motivated
bloatware) and have puttered along on macOS for the last decade or so—a change
is probably due, I'm just not sure there exists what I want, really. We'll
see. I'm rocking Void now and it's... fine, I guess. Kinda.

~~~
owenmarshall
> OpenBSD seems even nicer but I also like having, you know, software and
> drivers that Just Work™, which already seems like it might be a problem on
> FreeBSD.

It obviously depends on what you're using, but don't discount it without
glancing at driver support: I've had it running quite nicely on a handful of
laptops – typically older Thinkpads and Dells – and the "just work" factor of
the overall OS is _through the roof_.

~~~
enriquto
Have you noticed any problems with cpu throttling or hibernation? This is what
I'm most afraid about switching to openbsd on my laptop (Dell precision).

~~~
owenmarshall
Just works on my Thinkpad x220. You should, however, look for a dmesg output
referencing your system and see if anyone has reported bugs. Power management
is universally evil ;-)

------
gorgoiler
Sudo serves one purpose well: for admin users to become root _with an audit
trail_.

Why in 2020 do we still have non admin users on a host? Services! I still have
non-admin users on my hosts for www, databases, etc.

Without sudo, the alternative would be for ssh to PermitRootLogin which is
theoretically safe if root has a strong password etc, but in practice — should
there ever be a bug in openssh that exploits permissive root logins — would
needlessly expose systems to such a bug.

~~~
em-bee
the problem with sudo is that it requires a password. on servers i use ssh
keys to log in. i want that audit trail too, but either i set up sudo without
a password, or i have to manage a user password as well. on some systems i
thought to use ssh locally with a key, but then i need PermitRootLogin which
doesn't distinguish between local and remote logins.

------
zeroimpl
The stack exchange post is asking specifically for Desktop users.

But for shared linux servers, sudo is very useful. It allows controlling which
users are allowed to administer the system. (Generally, people who aren't
sudoers can only view log files or do other readonly things). It's much better
than letting people login as root directly since it keeps an audit trail of
who is actually administering the device (they will show up using the `users`
command, for example).

I rarely use sudo to do any fine-grained access control - it's almost always
an all-or-nothing configuration - specific users are granted full access (with
passwords), and everybody else gets none. I suppose this means that I use only
5% of it's functionality, but this 5% is quite useful.

~~~
millstone
Aren't shared Linux servers a thing of the past? I thought they were mostly
obviated by VPSes.

~~~
zeroimpl
I don’t mean like shared hosting servers in the cloud. I mean application
servers, build servers, and databases, hosted in-house. You don’t always want
to give the junior dev root access.

------
easterncalculus
Sudo provides access control for root access, it's definitely not useless.
Sudo allows for logging and locking of root actions. Those settings can be
configured irresponsibly and lead to compromise for sure, but the main purpose
is creating a sense of order to who can access what protected resources.
Without sudo (or doas, or something like that), you're just running su
whenever you want without real access control. For a timeshared system with a
lot of users, handing out root in this fashion is especially irresponsible.

~~~
closeparen
If a malicious sudoer has access to basically any system utility that takes a
filename, and the filenames are not explicitly enumerated in sudoers, you're
owned. The only way your claim here really holds is if you're limited to very
specific pre-defined scripts with limited degrees of freedom in their
arguments.

That is a fine thing to do. But when your operational processes are that
structured, you're more likely to be doing code-reviewed changes to a
configuration management repo, poking the API of a cluster scheduler, running
playbooks in Ansible Tower or Jenkins, or something else that doesn't involve
personal shell access.

~~~
easterncalculus
Your point certainly stands, a lot of privilege escalation occurs because of
sudo configurations like that. The idea that fine-grained access control
necessarily implies that you're using something like Ansible or Jenkins for
everything isn't necessarily true though, there are plenty of reasons why you
wouldn't want to use those packages specifically, or if it's just an old-
school timeshared computer. Sudo regulates those other utilities, and not the
other way around. Even if using something like Ansible sudo is great because
of the logging that it provides. Sudo works as a standard way to regulate
admin (or other group) access, whether automated or not. That's why Ansible
uses sudo as the become_method by default.

------
RIMR
The most important feature of sudo isn't what it does, but what it doesn't do.

What it doesn't do is run everything with root permissions giving every
process you run access to the entire filesystem, which is what you would be
doing without it.

~~~
icedchai
In theory. The reality is most people just use it to run "sudo bash".

------
LinuxBender
sudo is great for phishing. If I want to take over a system, I just need the
users password. Given that sudo is almost never set up correctly and is
unrestricted to anyone allowed to use it, I just send a script that requires
sudo, capture the password, then relay the password in a DNS request back to
myself. All in good red teaming fun, of course.

~~~
Jnr
So, you send someone a script... And they just run it?

If they do, then it doesn't matter if it uses/fakes sudo, or not. They have
some bigger problems.

~~~
nelgaard
But that is one reason I do use sudo.

I have some extra user accounts that I can sudo into to run scripts, plugins
etc from e.g., github that I trust somewhat but not 100 percent. In case they
do start mining bitcoins or sending spam mail I will find out and stop it.

------
sojsurf
Our teams do not use sudo primarily to gain root privileges. We use `sudo sh`
to switch contexts to a non-root user with different privileges. This allows
us to modify web application code in the security context that it executes in
(lower privilege).

Occasionally we do need to access system level resources, and `sudo` allows us
to do this in a way that forces us to acknowledge that we are doing something
more dangerous. However, we prefer using automation tools such as Chef to
accomplish those things in a measured, repeatable way.

------
amanzi
I work in a mixed environment of both Windows and Linux and in my opinion sudo
is very similar to Windows UAC and local admin rights. In that, you can give
someone access to a computer without sudo or local admin rights and they won't
be able to make any system-wide changes. But for someone who does have sudo or
local admin rights, then it's just a safeguard that should hopefully make the
user think twice before escalating their privileges.

If a Windows user is tricked into downloading some malware, and runs it by
using their local admin rights to bypass the UAC prompt, then the system is
owned. I believe this is the same risk with sudo, although the hope is that
the extra authentication prompt gives the user the opportunity to re-evaluate
whether or not they want to run the command as a privileged user.

------
geofft
1\. There's value in sudo (or su, or ssh root@localhost, or whatever
alternative you like to logging in directly as root) as a safety measure,
which is different from a security measure. Not having a paper towel holder
wall-mounted above your stove is a great idea to prevent accidental fires, but
it's completely irrelevant to stopping an arsonist. It's worth distinguishing
these two cases.

2\. sudo can be used for both running a limited set of commands and for
running an unrestricted set of commands. These are also two different cases.
It's a bit tricky to ensure your limited set of commands are secure (you need
to make sure none of the commands allow you to run unconstrained commands in
turn), but if you do it, that _is_ a meaningful security limit compared to
giving a user account unrestricted sudo or running that code as root. This
isn't usually relevant for typical desktop systems, but if you're looking at
designing some more involved deployment, it's relevant.

3\. For a multi-server deployment with a team of sysadmins, the question isn't
really about sudo vs. su vs. ssh as root - the question is about the chain of
accounts between a sysadmin's keyboard and their privileged shell. If you can
come up with a design where the account that they can use (directly or
indirectly) to log into root is more highly trusted than their everyday
account (the one they use for downloading software from the web and trying it
out, running code written by other people in the company, etc.), _then_
there's a meaningful benefit. There's a lot of ways to do that. One is to
allow them to log in from their workstation's account to both a privileged
sysadmin account with sudo and an unprivileged everyday one, and they do their
work logged in elsewhere with the unprivileged account. One is to allow them
to log in from their workstation's account directly to root, or to an
unprivileged everyday account - it's weaker in terms of auditing but it has
the same security properties as the previous solution. One is to set up
multiple local accounts on their workstation, one privileged and one not, so
they can work locally with their unprivileged account. The important bit is
that the unprivileged account can't escalate to the privileged one. It doesn't
matter if it does so with sudo or with su or with ssh or whatever, all of
those can be used to escalate privileges.

If you really want, you _can_ apply the scheme above to your desktop system.
Make two accounts, have one be an admin account and one not. If you're
installing drivers etc. switch to the admin account, but otherwise work in the
non-admin account. If the non-admin account gets broken into, you can reliably
use the admin account to wipe it and restore from a known-clean backup. That's
generally annoying in practice, though.

------
IshKebab
It's definitely a design flaw that sudo doesn't use a secure attention key,
and because of that, it adds no security at all in its normal configuration.
But implementing that is probably impossible given the Linux desktop's lack of
overarching design, and the fact that nobody cares about it (even a basic
login doesn't have a SAK; Windows had that back in Windows 2000).

I'm pretty sure X doesn't support SAKs at all - any program can intercept any
keystrokes. Maybe Wayland does, but then you somehow need to integrate your
sudo binary with Wayland. And good luck getting that to work over SSH.

------
Discombulator
Security is about trade offs. Talking about absolutes makes barely sense in
this context, because any perfectly secure system is also perfectly useless.

Despite the chosen solution on SO - and from how the question is stated, it is
clear that the asker only wanted confirmation -, sudo has its uses, even if is
not perfectly secure (especially with the default configuration).

I suggest a more sensible approach for all security-related discussions: All
systems have vulnerabilities, but some improve your security posture.

------
jandrese
One thing sudo does is prevent a local app takeover from completely owning
your system. In particular, it can prevent a ransomware type attack from being
able to touch your backups and makes it more difficult for the attackers to
leave a persistent trojan in your system, especially the kind that can survive
a reformat/reinstall or one that sniffs your network traffic.

------
jasonhansel
Here's my question: should we just give up on using Unix permissions (or ACLs)
for access control, and just containerize everything to limit access? That
seems to be where things are headed.

------
brodouevencode
sudo is like CICD in the respect that it protects you from yourself.

------
perryizgr8
I just always login as root. As long as I'm careful, I don't think I'll get
infected. If I'm not careful, sudo will anyway not save me.

------
Jnr
sudo does what it is supposed to do - run commands as a specific user. Without
entering password every time you run a command (because of caching). Depending
on parameters it will also evaluate some parameters for that user.

If you don't have particular use for it, just don't use it.

------
Koshkin
Anything is better than having root account enabled.

~~~
nix23
Like sudo su? Is that better(thanks ubuntu)?

~~~
smacktoward
The root account is a loaded gun. Sudo su is a loaded gun with the safety
engaged. You can still shoot yourself with it, but you have to take an
affirmative action first (disengaging the safety/sudo su), which cuts way down
on the number of trips to the emergency room.

~~~
Koshkin
It's not just that. The 'root' account as such has no personality associated
with it, so if two or more people share the password, all bets are off.

~~~
nix23
Yes absolutely, if sudo can make su, there is no more safety or audit in
place...to go back to gun's...glock, you pull or you don't, no switch just
'sudo su'

------
danans
Yes, it's mostly useless but it's also interesting to consider sudo in the
context of its history, and how computing has changed in a way that's made it
less useful.

sudo was most useful when computing mostly occurred in shared runtime
multiuser environments, as found in many research universities from the 1970s
through the early 2010s. It was useful in this situation because it allowed
selective granting of privileges to regular users (students, researchers,
professors) to run commands otherwise only available to the superuser (sudo =
"substitute [root] user do").

Those were the days of asking your sysadmin for root access to do something
potentially dangerous to the system or disruptive to other users on the shared
Unix system (i.e. running the "shutdown" command, or listening on a reserved
network port). sudo allowed the sysadmin to trust specific users with certain
commands they wouldn't otherwise be able to run.

sudo (and its GUI equivalents) was then adopted into personal computer OS's as
part of the first push to secure consumer OS's against their own users
corrupting them inadvertently, or via the emerging problem of computer
viruses. At the time, consumer OS's (win3.x - win95, original MacOS) ran all
software with administrative privileges.

Those OS's were replaced by enterprise equivalents that were designed with
stronger access control features (windows NT, and the BSDs that became
MacOSX).

The idea was that common tasks of the time (i.e. word processing,
spreadsheets) would run as regular user accounts, and things like installing
software or changing system settings would trigger a password prompt), just as
happens in an enterprise or shared multiuser environment.

But consumer OS's basically have a single logged-in human user at a time.
Thanks to the web, when computation needs to happen on a remote, shared
compute machine, it happens over some form of RPC or API. Other concurrent
"users" on most computers are usually system processes, not real users. How
many of us login into a remote _shared_ "compute" system anymore? Heck how
many of us even remember doing that?

Mobile OS's, and increasingly desktop OSs are evolving into managed runtime
environments, which by design have no facility for "root" access at all, often
to the chagrin of tinkerers who miss having the ability to modify OS
internals. Even server-based apps are designed to run in containers that run
in managed server environments.

Anymore, there's hardly a good reason to design most systems and software to
require root access to install or run anymore. And yes, there are exceptions
to this but those are usually for legacy software, or very specialized use
cases like OS development itself.

------
kempbellt
To each their own, but in my experience, both professionally and personally, I
find `sudo` to be mostly useless, and an annoyance at best (which can be good
for some people, just not me). My typical use-case for `sudo` is: _do X_ , oh,
I need sudo permissions, _sudo !!_.

Any time I'm on Linux, I usually operate as root to avoid this annoyance and I
put more weight into securing the machine in other ways - IP restrictions,
cycling keys, cycling the servers, etc.

Sudo can prevent rookie mistakes, like wiping an OS or removing certain
directories, but I consider most machines I work on to be ephemeral anyways,
and anytime I make one of these mistakes it is a reminder to not do that next
time - I prefer this to being hand-held and denied access superficially.

Oddly though, I do like that `sudo` exists in its current form, for people who
are not as experienced. For me personally, I almost never interact with it.

~~~
em-bee
i don't like sudo commands to clutter my history. i use tmux and run an
interactive root shell (started with sudo of course) as one of the windows. i
never work in that window unless i need to.

