>Do people work under the assumption that sudo is meant to protect against malicious actors?

I wonder if it comes from having a windows mindset and the way windows screams at you about unauthorized software and forces you to use an administrator password for random arbitrary things while saying it's for your protection. With windows background as a single user operating system, heavily targetted by malware this makes sense.

Then they come onto linux, find out they need to use sudo to install things from package managers or access files in the root directory and immediately that protecting themselves mindset comes into play. However, taking into account Linux's background as a multi-user operating system, this mindset makes less sense as the tools while working similarly at a shallow level, were designed for totally.different purposes.

Seeing that what you describe is a fairly recent thing in windows in the larger scale of things (assuming you talk about the UAC prompt): I'm not sure that has much to do with it. I met people working under that asumption 2 decades ago as well.

random arbitrary things

From what I can see that's not the case at all. In fact for me it seems rather sudo-y. Want to change system files? Need sudo / UAC. Want to install software (which is basically like the first case)? Need sudo / UAC? Want to screw up your home directory? No need for sudo, no UAC.

Depending on your UAC protection level, you might have to enter your password for normal Settings and Control Panel changes too.

Additionally, a lot of registry settings are things that should be user settings. Want to remap caps to escape? That would normally be a per-user window manager setting on Unix, but on Windows you have to use the Registry Editor.

The keyboard remapping in the Registry Editor is done at the kernel level, so of course it is a system-wide setting. There's a new PowerToy for Windows that does key remapping at the "window manager" level and does not need administrator access unless you want to also remap that key in administrator applications.

Most of the other "normal" Setting/Control Panel changes that need UAC prompts for certain classes of users have similar explanations. What Windows considers a system-level or multi-user setting certainly differs than *nix, but it doesn't necessarily mean there isn't a good reason why it differs.

Some of that is that Windows (NT branch, XP+) is a multi-user operating system most widely deployed by people that assume it is a single-user operating system and exacerbated by confusion where Windows mostly pretends to be compatible with a single-user operating system legacy (3.x/95-ME) right up until it cannot anymore and sometimes the multi-user-ness comes out to bite.

True, but that's still not really what I'd call random or arbitrary.

registry settings are things that should be user settings

User settings are most of the time registry settings since that thing is used where other OS use plain files :) But I know what you mean, some of the choices which were once made are strange and because of the sometimes annoying "let's keep things backwards compatible forever" principle it's also not likely to change soon. Then again, pretty sure for remapping there are workarounds in the form of creating your own keyboard layout for which MS has tools. Now if changing a keyboard layout still requires a UAC prompt (I really hope it doesn't) you're still nowhere.

Just to say more directly say what someone else said: this is ahistorical. What you're talking about, Windows UAC, is a relatively recent innovation in the Windows world, first introduced with Windows Vista. Obsession (maybe well-placed) with limiting usage of root for security reasons was a concept in Linux system administration well before that.

Also, the normal UAC setup for a consumer device does not require a password, just pressing a button.

> I wonder if it comes from having a windows mindset and the way windows screams at you about unauthorized software and forces you to use an administrator password for random arbitrary things while saying it's for your protection.

As a novice Linux user, that was exactly my mindset and reasoning.

>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?

>An unprivileged user shouldn't be able to take down a production system

Why do these people have shell access to production systems in the first place?

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.

But an unprivileged user can't do any of that. The entire point of unix permissions is so you can't mess with other users' files unless you've explicitly been granted permission. File owned by, say, mysql are owned by a separate "mysql" user by default.

If there are readable configuration file sitting around, then it's totally possible to get the credential for other systems. I see this stuff all the time and have leveraged t his fact for troubleshooting systems that I'm unfamiliar with.

> 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.

You know what is meant. This kind of pedantry doesn't add to the conversation.

"Theft" is a nice easy word for making a copy of data that you do not have permission to access.

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

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

DoS attack, ex: consuming CPU or RAM resources.

That’s a class of attacks that sudo doesn’t even pretend to address. I’m not championing sudo, but consider it as one piece of a “Defense in depth” approach.

I believe the commenter was more talking about giving shells to a daemon than any sudo shenanigans.

I reread, can see that now. I think the commentor was speaking to a conversation that had shifted. I’ll leave my comment but also vote them up - theirs was a fair point.

cgroups let you limit a user's usage of system resources. Like disk quotas, you need to configure this yourself if this is a threat model you care about, but it comes out-of-the-box with all modern distros.

> An unprivileged user shouldn't be able to take down a production system

How about deleting everything under /var/www/?

An unprivileged user can't do that. /var/www/ will be owned either by root, or (by default on debian, depends on your distro) www-data. Your unprivileged user can't modify other users' files, that's the entire point of unix permissions.

Given

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

> That's not really true. An unprivileged user

We can see that "unprivileged user" equals to anything that is not root in your post. Considering that definition www-data is an unprivileged user which can delete everything under /var/www/.

So no, what you are saying is not really true.

But www-data doesn't get a login shell, so it can't[1].

Obviously a user can modify their own files. The idea is if you compromise unprivileged user "scott", with their account, you can't harm other users or the system itself.

[1]easily. Technically it depends, but a hardened configuration would only give www-data permissions to read files its data files in /var/www, not write them (which includes delete), apart from things it actually needs to write like its app logs (and even then you should be using syslog facilities, which only let you write, again not delete or cause any issues). Principal of least privilege and all that. For fun, try to figure out how to ssh into your system as www-data and see the half dozen different roadblocks that come up in your way.

>Do people work under the assumption that sudo is meant to protect against malicious actors

>only running `sudo service` so they can log in an restart a service, but not make any other changes

So you think too, its a security measure?

You're having trouble thinking about security, where the goal and the threat are as important as the solution.

For example, a short fence can be considered a security measure, though it can be purposefully stepped over. Maybe it only serves as a guide, or maybe it protects a window from a nearby soccer field.

In that same way, the sudo example you're deriding can provide the 'security' of making the proper workflows more visible to the user- without being designed to keep out a malicious professional hacker.

Sudo in this instance is an easy way to allow the user to call service without giving them root access, thus a security measure. It has nothing to do with making things more visible to the user.

Well sudo for me has one good point, i can see witch person did something with root-rights, a bit like a lightweight auditd, but security to me really means something else, its here or its not, correctly implemented or not (in a technical and especially in the management space)

While you're right, this might be a reasonable compromise if you trust the person. The advantage of restricting their sudo use is to make it harder for them to accidentally mess something up, not protect against a malicious user.

> The advantage of restricting their sudo use is to make it harder for them to accidentally mess something up, not protect against a malicious user.

What makes you think that?

Security to me means that someone that can restart a service can 'really' don't do anything else, if i trust 'the' peoples they have already root/management-console access etc, if not they have a jail/container etc. Half-backed sudo-stuff has nothing to-do with trust nor security

Apologies, I thought the distinction here was clear.

I don't think it's useful in protecting against people with the intent to break stuff. A malicious person doesn't necessarily need root to do damage, and if they do, then there are many vectors for obtaining elevated privileges from within a shell.

I do think that it's useful for keeping users from within your organization from doing damage by accident. Like, you could enabled a person to log in and restart a service, but prevent them from mucking around with configurations.

Training wheels on a bicycle make it more difficult for an inexperienced rider to accidentally fall over.

They don't stop people from intentionally doing it.

When he need's training-wells he need a training-machine (aka dev-envoirement), everyone can fall over, but not because of sudo prevents that, but typing 1000 times 'sudo' is the same like clicking that windows thing.

PS: And the cold sweat after typing something like 'rm -rfd /' is still the best training-well

Sudo has nothing to do with training wheels.

It is an analogy..

Rider: Lean to the side

Training wheels: Hey! Whoah there. If you do that you will fall.

Rider: I know, do it anyway! (sudo...)

Training wheels: Your choice, I can only prevent so much.

Rider falls over...

If a user has sudoer privileges, sudo serves as nothing more than training wheels.

User: apt install APP

System: Access denied. sudo privileges required

User: sudo apt install APP

Sytem: Okie doke

And the age old `sudo make me a sandwhich` joke continues...

Sudo is an actual security measure though. You can be allowed to run "sudo service" but not "sudo apt" for example. Far from being a training wheel.

Except it is... It is implicit in the command being an acronym for "super user do".

`sudo X` => `super-user-do X` => `I really mean to do X`

For a user that has privileges to run a command, `sudo` is equivalent to Windows popping up the "Admin Privileges Required: OK? Yes. Done" prompt to run an app when you are already an admin.

If you are already an admin (or sudoer in the Unix world), why ask? Because the command you are running is potentially destructive and you want to double check? That's fine, but it is just like training wheels.

If a user is not a sudoer, the topic is entirely irrelevant, and if sudoers do not have permission to run certain commands that is a completely different question.

But to answer the original question, "Is Sudo Almost Useless?", the answer in most cases is yes.

> I always considered it an administrative tool to differentiate between authorized users and administrators.

For that you could just do

    alias sudo=su -c

if you want the admin (root) password to be different from the user (authorized users) password.

I suppose the main advantage of sudo is it gives you more granular control over which commands are allowed and which aren't. For example if you're building a robot, you can allow the robot's process access to /sbin/shutdown to be able to restart the system on remote command (or lack of remote command).

> alias sudo=su -c

This will not work. sudo cp aaa bbb will work but su -c cp aaa bbb will complain that the user aaa does not exist, you need to quote them instead, like su -c "cp aaa bbb".

It would make more sense to make it a script

    #!/bin/sh
    su -c "$@"

Or make it a shell function that operates on $@ in the same way, so you can put it in your bashrc with your aliases.

I tried this but didn't work:

    ~ :) gudo () { su -c "$@"; }
    ~ :) gudo echo foo bar
    su: user foo does not exist

I searched it up, and apparently "$@" and expands to "foo" "bar" while "$*" expands to "foo bar", and the latter is what we want. From a quick test on my machine, that replacement in in your function definition seems to fix it :).

This site is good to check out when evaluating specific Sudo permissions for users - https://gtfobins.github.io/

I always looked at sudo as being something between me and chmod 777 and inevitably bricking a distro.

Have done that (from root dir) out of desperation for some permissions issue I couldn’t figure out with -R flag before. 0/10 do not recommend. It’s worse than `rm -R *` because it leaves the hope of recovery.

sudo for me is anti-footshoot, but not a super-strong one:

  pi ALL=(ALL) NOPASSWD: ALL

(I must go check my reports... "This incident will be reported.")

Yes, they do work under that assumption. Just try announcing you run as root, anywhere with Linux users, and watch the pile-on.