171–180 of 282 posts
Earlier quoted context omitted.
Given that Ubuntu uses systemd like the vast majority of Linux systems nowadays, how does sudo-rs differ from run0?
sudo-rs doesn’t gratuitously require a root privilege daemon that regularly ships filesystem destruction and remote unauthenticated arbitrary code execution bugs. If your bar is “I’ll tolerate such crap”, you may as well run your desktop session as root.
Earlier quoted context omitted.
What should you do instead?
Capabilities. Proper microkernels already do that
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.
Earlier quoted context omitted.
Design the system so that you do not need users to escalate to root. Find each use case where a user may want to use sudo and then come up with an alternate way to accomplish that action from a regular account.
Currently, for any given action, the following possibilities are implemented: * 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 alternativ…
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.
Earlier quoted context omitted.
Design the system so that you do not need users to escalate to root. Find each use case where a user may want to use sudo and then come up with an alternate way to accomplish that action from a regular account.
That would just elevate each regular account to be a root account. There is no other way to make things like modifying files directly under / possible, or to change system configurations. You can lock everything down instead, then you have Android, but then you have certainly not enabled everything a user can do with sudo.
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.
Earlier quoted context omitted.
Design the system so that you do not need users to escalate to root. Find each use case where a user may want to use sudo and then come up with an alternate way to accomplish that action from a regular account.
We have that, it's called android. Anybody who finds themselves using sudo is already well off the beaten path, by their own choice. There's nothing wrong with that.
Earlier quoted context omitted.
Being a setuid binary means that sudo also suffers from attacks where an attacker runs `sudo ./malware` and then convinces the user to authenticate. Depending on how sudo authenticates phishing attacks or password reuse from another breach can be used to escalate privileges.
I don't see how this attack is related to the setuid binary. No matter what method you provide to the user to elevate their privileges, they can be tricked into doing it. If it was provided by a daemon, built into systemd, or anything else, the problem would be the same.
>If it was provided by a daemon, built into systemd, or anything else
Yes, this is also dangerous.
Earlier quoted context omitted.
Right, but now the vector for privilege escalation will have to be a logic bug in memory-safe sudo instead of either a memory corruption (see CVE-2021-3156) or a logic bug. It’s hard not to see this as a major improvement.
A major improvement would be to get rid of glibc altogether. As long as glibc is the default, the problems persist.
Earlier quoted context omitted.
Who are you shouting at? 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.
I'm not shouting. >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.
Earlier quoted context omitted.
> That would mean it's only using the same kernel as the Linux operating system? There's no "Linux operating system". Linux is the name of the kernel. Android is an operating system, GNU/Linux is, things like BusyBox/Linux are. They're all operating systems that use the Linux kernel.
Uh, didn't I say exactly that? Gnu/Linux Is just collegially known as "Linux" and the operation system suffix made it clear what he was talking about. I didn't come up with the usage of the term, I was merely trying to interpret their words.
Earlier quoted context omitted.
Being a setuid binary means that sudo also suffers from attacks where an attacker runs `sudo ./malware` and then convinces the user to authenticate. Depending on how sudo authenticates phishing attacks or password reuse from another breach can be used to escalate privileges.
I don't think you can realistically enforce a security boundary between root, and a user account that occasionally elevates. 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.
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.