I found an alternative implementation that doesn't rely in being a setuid binary like systemd-run0 much more interesting from a security perspective, but I am no security expert.
And it's also why it mostly has not happened for most people.
You can enforce a boundary between root and an account that never elevates though. And as far as I understand hardening sudo helps with that.
So stop doing that!
Anybody who finds themselves using sudo is already well off the beaten path, by their own choice. There's nothing wrong with that.
The beaten path is the defaults. Windows and MacOS particularly.
It doesn't need to be possible.
>change system configurations
You can have an settings app to configure the system.
>then you have Android
Which is much farther ahead than Ubuntu on security. Ubuntu needs to play catch up.
>but then you have certainly not enabled everything a user can do with sudo.
The goal is not to be able to do everything. The average user doesn't need to be able to do anything. Especially with their regular account.
* The user may never perform the action (would require sudo, but the user doesn't have sudo rights)
* The user may sometimes perform the action (i.e. only after authenticating with sudo)
* The user may always perform the action (is always implicitly authenticated)
"Being root" is just another name for the last option.
What fourth alternative do you have in mind?
No, it's not. Take for example ping. If we want users to be able to always be able to use ping does that mean they need to be root? No, it doesn't. A privileged part of the OS can handle doing the raw socket and the unpriviledged user can talk to that part of the OS.
The key point is that some operations that require privileges are okay to expose to a user, but giving the user privileges for everything is dangerous.
Unless you mean something like "capabilities are always inherited, and there is no way to increase them", which would mean that sudo-like scripts are impossible, and you need to start all-new session as root user for admin actions. Good news, it's already possible in linux - just don't install "sudo", and maybe set up SELinux to disallow all escalation. Turns out no one wants to do this though.
there's no god-mode who can do everything. there's no universal kernel level. micro means only minimal things happen in the kernel or at root level, like routing messages.
even windows understood that those times, when they did split Administrator from System. linux followed then with system users for certain services. but capabilities only allow certain calls at certain times. there's no setuid 0, only cap this and cap that for this admin user for a certain time range.
BTW, SElinux is the default on a proper linux like Redhat. I use it daily. I also have to adjust the ssh caps, not just the firewall settings. Everybody wants that, just not the debian nobs.
An agent logically has all the capabilities necessary to do what the agent should be able to do. The sum of capabilities of an agent indicates "the worst that can happen" if the agent is malicious. It makes sense that if a network service is malicious, all networking activities can be subverted. Still, the storage activities shouldn't be subverted, and of course the network service wouldn't have the storage service capability. However, if a user is malicious, anything could go wrong that the user is normally trusted to not make go wrong. Correspondingly, the user must have an expansive sum of capabilities.
Capabilities are themselves simple, but that is the mechanism perspective. Access control policy is an entirely different beast, and any mechanism at best minimizes the risks.
However, were were talking about "sudo" and this is purely interactive tool (I am sure some people run sudo non-interactively, but we can all agree it's a bad security practice). So, how does this nice capabilities vision mesh with the idea of "administrator user"?
From what I see, it's not much different. Instead of "sudo" which verifies user identity+permissions and then gives out "root" or some other user, we have some other hypothetical tool ("become-admin"?) which verifies user identity+permission and gives out powerful system-changing capabilities. Frankly, I don't see much difference - it's the same security model either way.
(A related argument I've seen is "you should not need sudo for common tasks like update software or configure network" - but on modern Linuxes, you don't need sudo for that already, this is done via dbus + polkit calls. No "proper microkernels" required, that is already deployed everywhere.)
Going back to the topic of the discussion, making sudo more resilient prevents a whole class of possible bugs (see CVE-2021-3156). You may not like sudo, but it is very commonly used to manage access, prevent accidental errors, or improve accountability on Linux servers and workstations. It is not going away. Therefore, improving sudo is a worthwhile goal and a thing to be celebrated.
>sudo more resilient prevents a whole class of possible bugs
Good, but this doesn't fix the easiest way to escalate privileges as an attacker through sudo. Memory safety doesn't help people who run "curl | sudo bash" to install a random program from the internet.
>It is not going away.
But if work is done it could become very niche and eventually stop getting new usage over time.
I don't think you can help those people, unless you seriously lock down the machine to the level of iPhone. Neither Android nor Windows have "sudo" for example, and yet they can get malware just fine... all the difference is instead of the password, user clicks on confirm button a few times.
I advice to (1) think about how you use sudo (2) think what would you replace it with and (3) think how the replacement can be abused by malware.
Here is one example:
(1) Today I used "sudo" to run docker: "sudo -Eg docker docker run..."
(2) the sudo-less replacement would be to add myself to docker group, or switch to rootless docker
(3) If I add myself to docker group, malware can trivially escalate by starting a privileged container. If I switch to the rootless docker, I am weakening security boundary between my primary user and the docker containers I run.
In text format, all-caps or the use of an exclamation mark are often used to indicate shouting.
So, it is not unreasonable for people to read your sentence as such.
Maybe you can't realistically do it on Linux, because Linux doesn't care about desktop security and doesn't have the kind of privileged GUI that you need.
It can't be enforced on Linux because `sudo` can be trivially MitM'd, but you can't do that on Windows because it's just a click.
Being a setuid binary means that sudo also suffers from attacks where an attacker runs `sudo ./malware` and then convinces the user to authenticate
That's why the OP said that's not an enforceable security boundary. If the user is capable of attaining superuser privs, you can trick them, regardless of how attaining those privs is implemented.
I didn't interpret OP's comment like that. I think he was saying you can't enforce the boundary at all even if users don't get tricked.
That's true on Linux because the sudo UI can trivially be MitM'd by malware. You can't do that on Windows so trivially.
[0] https://cyberdom.blog/abusing-the-windows-update-stack-to-ga...
* Privileged gui to display and approve what will run as you mentioned. In Linux, non-privileged gui is used to request permission to do... something.
* Executable verification. Let's say someone with user level permissions swaps out the program you wanted to run for a malicious one. The replacement would not pass certificate checks which would be revealed in the privileged gui. Maybe you could supply an old version with known vulnerabilities though idk?
* Kinda commandline parameters verification. In Linux-land you can pass parameters to the program those could be intercepted with user-level permissions. In Windows this would be displayed in the privileged gui. However! The parameters are only visible if you click "show more" which I would guess <1% of people actually do.
As an example of the last point I tested making a shortcut to cmd.exe and used Run As Administrator. Then I changed the shortcut to C:\Windows\System32\cmd.exe /c calc and again did Run As Administrator. Opens calculator instead of command prompt with identical approval gui (except with show more).
So does your OS.
>If it was provided by a daemon, built into systemd, or anything else
Yes, this is also dangerous.
I think the main benefit of eliminating setuid binaries is that you can forbid them system-wide (e.g. via mount flags), as a hardening measure.
The original unix process abstraction was extremely simple; the entire spec is a few pages.
The problem is that Linux keeps adding more and more levels of Rube Goldberg machine to its security model, so now literally no one understands how a default minimal install of, say, Ubuntu works.
Adding a magic daemon that runs stuff as root to this pile of complexity probably won’t help. Ripping out almost all the cruft that’s accumulated over the years, and adding back something sane (maybe BSD jails) would work a lot better.
The non-daemon has to parse just as much in addition to making itself secure. Actually it needs to parse more things in more complex ways.
Here’s a simple implementation: https://github.com/TheMilkies/rut/blob/main/rut.c
(Though it doesn’t clear the environment unless I’m missing something - they should probably replace the call to execvp with one to execvpe, and add a null pointer to the end of the argument list).
The problem of setting up root’s environment and parsing the command line is left to the shell in both solutions (the thing I linked doesn’t indirect through a root login shell).
There’s also the config file, but that’s the same for both.
Similarly, the system could be running some SEL derivative or be using a capability system that causes non-standard behavior from system calls, but the daemon has the same problem.
So yes, I am not saying that privilege escalation bugs are impossible if you have a different architecture, but like Lennart argues is that it makes them much more difficult to happen, especially because creating a proper setuid is difficult. Also there is a bunch of things that makes sudo especially tricky to implement correctly.
Eventually the bug (and associated vulnerability) was patched. I think.
I apologize, I do not bookmark these issues, but maybe I should start doing that? In any case, you will find logic bugs which may raise the question "is it really worth the rewrite?".
> I apologize, I do not bookmark these issues, but maybe I should start doing that?
Yes. If you want to point out problems, it really helps if you can point at specifics.
> In any case, you will find logic bugs which may raise the question "is it really worth the rewrite?".
There's a cost/benefit question, but note that the mere presence of some bugs doesn't make a rewrite worthless.