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.
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.
>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?
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 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.
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.
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.
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.
> >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/.
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?
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.
> 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.
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.
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.
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.
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.
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.
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.
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)
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
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.
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
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.
> 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).
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".
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 :).
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.
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.
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.
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.
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.
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'
> 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.
"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.
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.
> 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.
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).
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 ;-)
FreeBSD "just works" but you have to enable everything. If you plug a mouse, you'll have to enable usbmod (or whatever kernel module is responsible for this) by hand. Maybe I'm exaggerating with that mouse anecdote, but I remember I regretted not going with PCBSD which is a user friendly distrib of FreeBSD (now renamed TrueOS). If you consider using Freebsd as an everyday desktop computer, you'll save some time with TrueOS. Having said that, configuring FreeBSD, activating kernel modules etc, is really easy, both in terms of googlability and inner clarity. Probably because it's a distrib in itself, as compared to linux and its many subtle differences across distribs.
> I big fat "update the system" (or don't) button with my user-installed packages totally separate, as I get with macOS, is nicer.
Today we live in the land of plenty. Computer hardware is so cheap, it's practical to put together a respectable lab with gear literally pulled out of a dumpster. The reason Windows and Mac OSes have a sharper line between system software and user software is because modern advances have made computer cheap enough that not only does almost everyone have their own personal computer, almost everybody has more than one. As a result, Windows and Mac have always been mostly single-user systems. Yes, yes, they support having multiple _accounts_ but usually by one person at a time, which limits the number of accounts (as a practical matter) to a handful at best.
All of the major Linux distributions were designed in a time where large multi-user systems were the norm. Disk space was limited, memory was small, CPU cycles were few. Unix (and hence Linux) was designed to make efficient use of these limited resources by installing popular software system-wide with shared dynamically-linked libraries because that was the only way to even _fit_ a few hundred users on one system. As a sysadmin, I get cold sweats thinking about what would have happened if every user wanted their own personal copy of Emacs on such a system.
> Especially on a single-user system, I should be able to install most software without escalating privileges.
I do believe you can, see Snaps and Flatpak. These run on just about everything. But there is a steep price: user-isolated applications can take an order of magnitude more disk space and significantly more memory compared to OS-built packages, see https://www.reddit.com/r/pop_os/comments/gia8s1/flatpak_pack...
If you're looking for a Linux distro that behaves more like Windows and Mac, you're in luck because Ubuntu is hurtling themselves in that direction as quickly as they can by making snaps compulsory on every desktop install.
> I should be able to blanket-update my user-facing software without any risk whatsoever that a kernel update will get thrown in
So, I think you have it backwards. Kernel updates generally contain important security or bug fixes and you absolutely _should_ be installing those and rebooting _well_ before even acknowledging the existence of your userland apps.
> Disk space was limited, memory was small, CPU cycles were few
With that logic DOS/Windows and even Mac OS (X) should be even worse regarding that then, after all both Mac OS and DOS are older than Linux. Not to mention that servers always had better cpus/more ram compared to personal computers.
This is exactly what windows does. Most of the times the installers need admin privileges.
> see Snaps and Flatpak
Nix (which was mentioned by the person that you are replying to) is an even better solution. In fact you can run it on top of existing distros too. Also, package managers for programming languages (such as Haskell's cabal and even Python's pip I think) have Nix support now.
An alternative is to use appimage which is just a single executable per software.
> Unix (and hence Linux) was designed to make efficient use of these limited resources by installing popular software system-wide with shared dynamically-linked libraries because that was the only way to even _fit_ a few hundred users on one system. As a sysadmin, I get cold sweats thinking about what would have happened if every user wanted their own personal copy of Emacs on such a system.
I think this is largely beside the point, and not because concerns about resource use are outdated. Linux already has the concept of user groups. Just make packages installable per-group or per-user. There, issue almost entirely mitigated. The default case for single-user systems could even be group-install, since it'd look basically the same anyway—it's multiuser systems where true per-user package management might make sense, but isolation from basic system software management makes sense in either case.
> If you're looking for a Linux distro that behaves more like Windows and Mac, you're in luck because Ubuntu is hurtling themselves in that direction as quickly as they can by making snaps compulsory on every desktop install.
I'm no old-timer (yet) but my first couple computers had actually-floppy floppy disks, so I remember resource constraints well and remain conscious of them to an above-average level, I think. Ubuntu these days is buggy bloatware with little extra going for it in exchange, and has been for a long time. For ~3-4 years early on they were doing a good job of curating a decent Linux desktop experience with reasonable defaults (as in "Epiphany? LOL no, our desktop metapackage will install Firefox, TYVM") but those days are long past. Snaps are so plainly godawful that it's got to be internal politics that let them get this far, and keeping them alive—but such a thing is only a tempting development target because software management on Linux is all mixed up with keeping the system bootable and fundamental hardware features working to a basic level, which is the thing I'm not happy with.
> And have to update each software package manually as in windows/macos? (even worse, have a backdoor updater build-in on packages)
I only use Windows for gaming so IDK there, but almost everything I use on macOS is installed with Homebrew (a package manager). Even crapware like Slack. Though yes some of those do decide to use their own built-in updaters after that—no helping that, if you must use their software, but being able to script installation of them through one interface is really nice.
> But why?
It shouldn't be possible to break one's system with the same tool, commands, and privileges one uses to install Tux Racer. Installing normal user-facing packages shouldn't require privileges that even allow for screwing with basic system software.
> Any and all security updates should be installed as soon as possible, regardless if it is a kernel update or a browser update.
God damn I guess I picked a bad example because folks are really stuck on that. Reverse it then: if I want the latest drivers, xorg, and kernel, including feature updates, what's that got to do with my installation of Tux Racer? Why are those connected in any way whatsoever? Why do the same tools manage installing and updating both? "Build it from source then" yeah but I like package managers except for oddball stuff like dwm, I'm not saying get rid of them.
I could use Homebrew or Nix on top of some distro but that's a road full of jank and more fiddling-with-trivia than I have patience for these days. I'll crankily live with Void Linux for now and pine for a robust, small, tested, rock-solid base system built for using one or more complementary and supplementary user-facing package managers on top of. I mean macOS isn't even built for that, exactly, it just suits the case very well. I wish there were a Linux distro that did, too.
I haven’t tried it myself, but it sounds like you may find Silverblue Linux [1] of interest. It’s supposed to treat the base system as immutable images that are updated “atomically”, while user apps are handled via Flatpak, completely separated from this immutable base.
In other words, an OS model that sounds more like iOS and Android, but built on Fedora and targeted at computers.
yes and no. there is a benefit in having user applications installed as root or as some other system user. they can't be exploited by malicious software that runs with user privileges.
There's Fedora Silverblue [1] too. It's immutable so every installation is identical to every other installation of the same version. And then you install your Flatpaks isolated from the rest of the system on top of that.
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.
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.
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.
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.
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.
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.
Can you expand a bit on the type of scripts/scenario you'd use for something like this? I presume the email + script would need to be something legitimate enough looking as to not raise any red flags during a glance over, with built in assurances you aren't causing any real harm against the target, and then properly configuring the script (or downstream actions) to then get exfil'd. Very interesting nonetheless.
Maybe you don't want to leave any log traces, kernel mods etc behind yet before getting instructions from your c&c or waiting until a set time when some other coordinated action (or a weekend) happens.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
109 comments
[ 2.8 ms ] story [ 172 ms ] threadWhat 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.
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.
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?
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.
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.
"Theft" is a nice easy word for making a copy of data that you do not have permission to access.
How about deleting everything under /var/www/?
> >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.
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.
Why do these people have shell access to production systems in the first place?
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.
As a novice Linux user, that was exactly my mindset and reasoning.
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.
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.
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.
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.
Also, the normal UAC setup for a consumer device does not require a password, just pressing a button.
>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?
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.
What makes you think that?
They don't stop people from intentionally doing it.
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 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.
PS: And the cold sweat after typing something like 'rm -rfd /' is still the best training-well
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.
For that you could just do
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).
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
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.
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.
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.
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.
DRM update committed
Contributed by Paul 'WEiRD' de Weerd on 2020-06-08 from the faster pixels dept.
Jonathan Gray (jsg@) has just committed an update to the DRM code to the tree. This update brings support for newer AMD and Intel graphics parts.
[1] https://undeadly.org/cgi?action=article;sid=20200608075708
Today we live in the land of plenty. Computer hardware is so cheap, it's practical to put together a respectable lab with gear literally pulled out of a dumpster. The reason Windows and Mac OSes have a sharper line between system software and user software is because modern advances have made computer cheap enough that not only does almost everyone have their own personal computer, almost everybody has more than one. As a result, Windows and Mac have always been mostly single-user systems. Yes, yes, they support having multiple _accounts_ but usually by one person at a time, which limits the number of accounts (as a practical matter) to a handful at best.
All of the major Linux distributions were designed in a time where large multi-user systems were the norm. Disk space was limited, memory was small, CPU cycles were few. Unix (and hence Linux) was designed to make efficient use of these limited resources by installing popular software system-wide with shared dynamically-linked libraries because that was the only way to even _fit_ a few hundred users on one system. As a sysadmin, I get cold sweats thinking about what would have happened if every user wanted their own personal copy of Emacs on such a system.
> Especially on a single-user system, I should be able to install most software without escalating privileges.
I do believe you can, see Snaps and Flatpak. These run on just about everything. But there is a steep price: user-isolated applications can take an order of magnitude more disk space and significantly more memory compared to OS-built packages, see https://www.reddit.com/r/pop_os/comments/gia8s1/flatpak_pack...
If you're looking for a Linux distro that behaves more like Windows and Mac, you're in luck because Ubuntu is hurtling themselves in that direction as quickly as they can by making snaps compulsory on every desktop install.
> I should be able to blanket-update my user-facing software without any risk whatsoever that a kernel update will get thrown in
So, I think you have it backwards. Kernel updates generally contain important security or bug fixes and you absolutely _should_ be installing those and rebooting _well_ before even acknowledging the existence of your userland apps.
With that logic DOS/Windows and even Mac OS (X) should be even worse regarding that then, after all both Mac OS and DOS are older than Linux. Not to mention that servers always had better cpus/more ram compared to personal computers.
> Unix (and hence Linux)
Mac OS X is officially recognised as a Unix. Just one of the registrations: https://www.opengroup.org/openbrand/register/brand3581.htm
> installing popular software system-wide
This is exactly what windows does. Most of the times the installers need admin privileges.
> see Snaps and Flatpak
Nix (which was mentioned by the person that you are replying to) is an even better solution. In fact you can run it on top of existing distros too. Also, package managers for programming languages (such as Haskell's cabal and even Python's pip I think) have Nix support now.
An alternative is to use appimage which is just a single executable per software.
I think this is largely beside the point, and not because concerns about resource use are outdated. Linux already has the concept of user groups. Just make packages installable per-group or per-user. There, issue almost entirely mitigated. The default case for single-user systems could even be group-install, since it'd look basically the same anyway—it's multiuser systems where true per-user package management might make sense, but isolation from basic system software management makes sense in either case.
> If you're looking for a Linux distro that behaves more like Windows and Mac, you're in luck because Ubuntu is hurtling themselves in that direction as quickly as they can by making snaps compulsory on every desktop install.
I'm no old-timer (yet) but my first couple computers had actually-floppy floppy disks, so I remember resource constraints well and remain conscious of them to an above-average level, I think. Ubuntu these days is buggy bloatware with little extra going for it in exchange, and has been for a long time. For ~3-4 years early on they were doing a good job of curating a decent Linux desktop experience with reasonable defaults (as in "Epiphany? LOL no, our desktop metapackage will install Firefox, TYVM") but those days are long past. Snaps are so plainly godawful that it's got to be internal politics that let them get this far, and keeping them alive—but such a thing is only a tempting development target because software management on Linux is all mixed up with keeping the system bootable and fundamental hardware features working to a basic level, which is the thing I'm not happy with.
And have to update each software package manually as in windows/macos? (even worse, have a backdoor updater build-in on packages)
> 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
But why? Any and all security updates should be installed as soon as possible, regardless if it is a kernel update or a browser update.
I only use Windows for gaming so IDK there, but almost everything I use on macOS is installed with Homebrew (a package manager). Even crapware like Slack. Though yes some of those do decide to use their own built-in updaters after that—no helping that, if you must use their software, but being able to script installation of them through one interface is really nice.
> But why?
It shouldn't be possible to break one's system with the same tool, commands, and privileges one uses to install Tux Racer. Installing normal user-facing packages shouldn't require privileges that even allow for screwing with basic system software.
> Any and all security updates should be installed as soon as possible, regardless if it is a kernel update or a browser update.
God damn I guess I picked a bad example because folks are really stuck on that. Reverse it then: if I want the latest drivers, xorg, and kernel, including feature updates, what's that got to do with my installation of Tux Racer? Why are those connected in any way whatsoever? Why do the same tools manage installing and updating both? "Build it from source then" yeah but I like package managers except for oddball stuff like dwm, I'm not saying get rid of them.
I could use Homebrew or Nix on top of some distro but that's a road full of jank and more fiddling-with-trivia than I have patience for these days. I'll crankily live with Void Linux for now and pine for a robust, small, tested, rock-solid base system built for using one or more complementary and supplementary user-facing package managers on top of. I mean macOS isn't even built for that, exactly, it just suits the case very well. I wish there were a Linux distro that did, too.
In other words, an OS model that sounds more like iOS and Android, but built on Fedora and targeted at computers.
[1]: https://fedoramagazine.org/what-is-silverblue/
[1]: https://silverblue.fedoraproject.org/
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.
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.
Login to the developer’s machine as in? What if they disabled SSH password auth?
I mean, if you already made them run a random script why would you even care about their password?
If they do, then it doesn't matter if it uses/fakes sudo, or not. They have some bigger problems.
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.
If you don't have particular use for it, just don't use it.
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.
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.
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.
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.
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.
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.