> This move is part of a broader effort by Canonical to improve the resilience and maintainability of core system components. Sudo-rs is developed by the Trifecta Tech Foundation (TTF), a nonprofit organization that creates secure, open source building blocks for infrastructure software.
Ubuntu continuously updates itself without permission, killing apps and losing previous state. You have the Javascript based Gnome window manager that is always bugging out. The Ubuntu packages, drivers and kernel are laughably behind Debian and even further behind mainline. Ubuntu continues to morph into something I don't believe in.
That all said, Rust is not a smoking gun for incorrect application logic. It could still happily incorrectly execute stuff with the wrong permissions or blow something up badly. I think it's also a bad idea to offer it as a drop-in replacement when clearly features are still missing since a long time [1].
> That all said, Rust is not a smoking gun for incorrect application logic. It could still happily incorrectly execute stuff with the wrong permissions or blow something up badly.
This side steps the issue which is "Does Rust help you make software more correct?" No one is arguing that Rust is perfect. There are plenty of bugs in my Rust software. The question is only -- are we better off with Rust than the alternatives?
> I think it's also a bad idea to offer it as a drop-in replacement when clearly features are still missing since a long time [1].
Your example is the Github issue page?
Look -- I agree that, say, uutils/coreutils missing locales may frustrate some users (although I almost never use them). But "close enough" is more the Unix way than we may care to realize. Ubuntu wants to lay claim to "the Rust distribution" and it's hard to blame them when Linux wants to lay claim to "the Rust kernel". But especially in this instance, because sudo is not POSIX (unlike locales which are). A distro is free to choose any number of alternatives.
wkat4242 · 2h ago
I think you mean a magic bullet instead of a smoking gun :)
rzzzt · 19m ago
Fish in a barrel!
bArray · 1h ago
I meant "smoking gun" from a cyber security perspective, i.e. the conclusion or the final part of the investigation. "magic bullet" would also work here too though.
MaKey · 1h ago
Evidence, particularly of a crime, that is difficult or impossible to dispute. [1]
Even with your explanation I don't think it fits here.
You seem to have inferred the wrong meaning of "smoking gun" and that's why your usage above doesn't make sense.
There's no valid reason cyber security people would take a well known idiom and repurpose it as you imply, and a quick Google suggests they haven't done this.
nottorp · 53m ago
I have the hardware for a new home server waiting to be set up (as in, I don't need a new home server i'm just messing around, so once in a while i log in and configure one more service).
I tried the latest Ubuntu and it seems to be targeted at either containers or desktops. Everything I wanted to set up networking wise was a pain for my little non standard configuration.
Ended up wiping it and installing Debian instead.
As for this Rust thing, first question that comes to my mind is what features are missing from this new godly impervious to hackers by default implementation.
watermelon0 · 9m ago
Worth mentioning that many packages on Ubuntu are only available via snap, which includes docker-cli, so they cannot be used inside containers.
bayindirh · 40m ago
When there's Debian, Ubuntu is moot for servers and personal use (for power users at least).
One of my former colleagues used to install Ubuntu servers. I replace them with Debian when I get the chance. I was already blacklisted for Snap, so I can't re-blacklist them for going uutils and sudo-rs, and that's sad (as in Bryan Cantrell's presentation).
Spivak · 1h ago
> Ubuntu continuously updates itself without permission, killing apps and losing previous state.
What? Is this some snap thing because apt sure as hell doesn't do this without you configuring it explicitly.
passivegains · 27m ago
apt won't on its own, but if you're using the official images there's probably a service running that's calling it, probably for security patches etc.
The bigger problem is upgrading packages deliberately but being surprised by the results. My team's current favorite is the upgrade process itself suddenly having new interactive prompts breaking our scripts.
kokada · 6h ago
I am not sure if memory-safety is the biggest issue in sudo design. I find the fact that it is a setuid binary a much bigger issue because a bug can possible result in privilege escalation.
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.
MajesticHobo2 · 5h ago
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.
h4ck_th3_pl4n3t · 1h ago
A major improvement would be to get rid of glibc altogether. As long as glibc is the default, the problems persist.
charcircuit · 5h ago
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.
remram · 1h ago
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.
jvanderbot · 5h ago
Those will also have to be fixed/considered, but do not detract from the contribution of removing memory safety bugs which may enable exploits.
charcircuit · 4h ago
This is a case of doubling down on bad design. To me it's wasted effort preventing theoretical bugs in niche setups.
jvanderbot · 4h ago
I think the opposing view is that moving away from sudo is substantially more effort and would break basically everything to accomplish "the same" thing as robustifying sudo (for some very loose definition of "same")
charcircuit · 4h ago
Yes, it's more effort, but it's not close to being the same.
pixl97 · 1h ago
I mean moving from IPv4 to IPv6 is more effort, but it's not close to being the same...
And it's also why it mostly has not happened for most people.
a_t48 · 4h ago
Even with a new, perfect paradigm, there would be billions of systems running sudo for years.
zahlman · 27m ago
Do you have in mind a design that enables users to escalate privileges while preventing them from being tricked into escalating privileges?
im3w1l · 4h ago
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.
charcircuit · 4h ago
>I don't think you can realistically enforce a security boundary between root, and a user account that occasionally elevates.
So stop doing that!
msm_ · 4h ago
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.
charcircuit · 18m ago
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.
z3t4 · 4h ago
What should you do instead?
rurban · 3h ago
Capabilities. Proper microkernels already do that
theamk · 5m ago
[delayed]
charcircuit · 4h ago
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.
onli · 3h ago
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.
zahlman · 23m ago
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 alternative do you have in mind?
charcircuit · 1m ago
>"Being root" is just another name for the last option.
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.
lupusreal · 3h ago
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.
hulitu · 3h ago
> Being a setuid binary means that sudo also suffers from attacks where an attacker runs `sudo ./malware` and then convinces the user to authenticate
So does your OS.
Retr0id · 5h ago
A bug in a daemon-based sudo alternative would surely also result in privilege escalation?
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.
JoshTriplett · 5h ago
There's value in always starting processes from a known-secure environment rather than attempting to transform a user's arbitrary environment into a secure one.
Retr0id · 5h ago
True, CVE-2021-4034 comes to mind as a recent example (exploiting zero-length argv)
hedora · 5h ago
How is that any different than a daemon that has a parser error in its message handler, except that the daemon could be misconfigured to listen on a network socket?
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.
Dylan16807 · 5h ago
> How is that any different than a daemon that has a parser error in its message handler
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.
hedora · 4h ago
Assuming static linkage (which sudo has to assume), there’s really not much to parse. It should just be dealing with a null-delimited list (argv) and the caller’s environment variables (which it just needs to ignore and clear by default).
(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.
johnisgood · 3h ago
Rust version of sudo had lots of ridiculous logic bugs. I do not see the improvement.
TrueDuality · 3h ago
Do you have an example of the logic bugs you're referring to?
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?".
internetter · 2h ago
You have the burden of proof to substantiate your accusations. Until then they're entirely unfounded.
Gabrys1 · 4h ago
> Ubuntu is the most widely deployed Linux operating system
Nitpicking, but I thought Android was the most widely deployed Linux OS around...
apexalpha · 1h ago
You are correct but in this context Linux means GNU/Linux.
Bit like how tomato is technically a fruit but everyone knows that in the context of a supermarket it’s a vegtable
pietro72ohboy · 1h ago
Ironically, Ubuntu's efforts to replace its GNU components with non-GNU alternatives is very quickly going to turn it back into just Linux.
dist-epoch · 4h ago
That's the logic Oracle uses to say Java is the most widely deployed language in the world, because it runs on phone sim cards and credit cards
FpUser · 3h ago
I was Ubuntu user until they've introduced snap and started forcing it down everybody's throat. No more Ubuntu for me.
pphysch · 4h ago
Maybe "deployed" is the key word here. Android is treated like a fixture of mobile devices rather than a fungible Linux distro.
Ygg2 · 3h ago
Some would say that Android isn't Linux OS[1]. It runs Linux, in same way Linux runs Wine. As a (POSIX) compatibility layer.
Android uses the Linux Kernel, but iirc (correct me if I'm wrong), it doesn't come with the required application to make it Unix and hence is not the Linux operating system. That would mean it's only using the same kernel as the Linux operating system?
Idk, just speculating to maybe get the thought process
flexagoon · 2h ago
> 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.
ffsm8 · 1h ago
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.
steveklabnik · 3h ago
> it doesn't come with the required application to make it Unix and hence is not the Linux operating system.
Ah, interesting to know. I guess it is only the coreutils stuff where that is a concern
johnklos · 2h ago
"This move is part of a broader effort by Canonical to improve the resilience and maintainability of core system components."
Somehow "maintainability" has never been something I'd ever associate with Ubuntu. Is it a reference to their source tree? That'd make a lot more sense than if they were referring to the OS itself.
This one is easy: run0 is not implemented in a memory-safe language, but in C. It is likely to be hit by exploitable memory-handling bugs, like the rest of systemd, as has happened multiple times before.
paulddraper · 5h ago
A trivial Google search answers that. run0 requires systemd-type OS.
ranger207 · 5h ago
Given that Ubuntu uses systemd like the vast majority of Linux systems nowadays, how does sudo-rs differ from run0?
fweimer · 5h ago
You might not have a systemd instance inside a container, but you still might want to switch user IDs there.
paulddraper · 3h ago
sudo-rs uses setuid.
run0 does not (and instead relies on systemd).
---
To answer your next question: setuid, while historic, is a bit weird, and is disabled in some environments, e.g. NoNewPrivileges.
hedora · 4h ago
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.
zahlman · 8m ago
If sudo does this, as you imply, why do Linux system still exist that are not part of a botnet?
postepowanieadm · 2h ago
No one is rewriting systemd in rust?
steveklabnik · 2h ago
I'm not aware of any serious project to do so, there's been some small projects, nothing on the scale of uutils or sudo-rs.
Rotundo · 8h ago
Did sudo have memory problems? Did it ever fail because it didn't handle its memory correctly?
mid-kid · 7h ago
There's been cases[1], of particular note, the unescape overflow one[2]. This one scathed the reputation of sudo enough to get people pushing for alternatives such as doas. The track record of vulnerabilities in general leaves a bit to be desired, even outside of memory vulns.
Sudo had quite a few problems with security, partially because of this doas was developed for BSD.
Some problems come from the huge amount of features(ldap, easter eggs, ...).
sudo-rs reduces the problems by not implementing those features.
mrweasel · 36m ago
Ubuntu moving to a memory safe sudo implementation isn't actually that concerning to me. It's a good idea to have a smaller, safer sudo alternative as the default, as OpenBSD does with doas. Users can install sudo if they need it. My problem is that it needs to specifically be called something else than sudo. Again OpenBSD has doas, which to the users clearly isn't sudo, so users don't expect it to behave as sudo or configure as sudo.
By all means, write a better, safer, smaller, more secure version of sudo, but don't have command be sudo or sudo-rs, name it something else.
ch_123 · 6h ago
> Some problems come from the huge amount of features(ldap, easter eggs, ...). sudo-rs reduces the problems by not implementing those features.
This makes me wonder:
1) Would a hypothetical "sudo-lite" with these features removed lead to better security without a rewrite?
2) If these features are useful in the real world, will a Rust rewrite of sudo inevitably gain these features over time and end up with similar problems?
steveklabnik · 3h ago
2. While a feature may be useful, the question is how useful, and to how many people. sudo-rs is removing features that aren't used very much, if at all, and doesn't plan to add them, to combat this. Those users can still use the original sudo.
throw0101a · 5h ago
> 1) Would a hypothetical "sudo-lite" with these features removed lead to better security without a rewrite?
"without a rewrite" means cutting down the existing code. A completely different program goes into the same category as "rewrite".
0cf8612b2e1e · 2h ago
doas is 500 lines of C. Two orders is magnitude less than sudo yet still covers the core functionality. Sure you could grandfather”s axe your way into the final product, but difficult to see how a a hypothetical code base 1% of the original counted as anything but a rewrite.
Dylan16807 · 25m ago
Your phrasing sounds like you disagree with me, but you're saying the same thing, right? That doas is not an example of "without a rewrite".
literalAardvark · 5h ago
It can't end up with similar problems, due to the memory safety guarantee.
That's not to say that it won't create other ones.
ch_123 · 36m ago
There are many types of security problems beyond memory safety issues.
XorNot · 6h ago
Removing LDAP is a huge problem for the more important sudo deployments though: centralized management of permissions is kind of a vital function.
JoshTriplett · 5h ago
Debian is currently in the process of dropping the direct LDAP support in sudo, in favor of sssd. From sudo's NEWS.Debian.gz:
> In practice, there are few installations that use sudo-ldap. Most installations that use LDAP as a directory service and sudo have now opted for sssd, sssd-ldap and libsss-sudo.
> The Debian sudo team recommends the use of libsss-sudo for new installations and the migration of existing installations from sudo-ldap to libsss-sudo and sssd.
XorNot · 5h ago
Ah that makes more sense.
rnijveld · 1h ago
The features we specifically don’t support are those related to direct LDAP support within sudo, so things like loading a sudoers file directly from LDAP. Sudo-rs will use any user retrieved via NSS, such as when configured using SSSD to load LDAP users. And from the authentication side you can use whatever PAM supports, so anything like Kerberos etc, which again can be coupled with the same LDAP database.
Filligree · 6h ago
Those people can keep using sudo; it’s not going away. The rest of us get better security.
fluidcruft · 6h ago
Is it actually removing ldap or is it offloading to pam?
dec0dedab0de · 5h ago
Could you clarify what you mean by more important sudo deployments?
I have been using sudo-rs for over a year. The only issue that I've had is running into `-E` being unsupported once every few months - which is arguably a good thing because I shouldn't be naughty and allow arbitrary envs to leak into a privileged session.
dev_l1x_be · 5h ago
doas is a much simpler (and therefore better) alternative.
Foxboron · 4h ago
doas is a really bad option on Linux.
The Linux port has not been maintained for 3 years. Has unmerged rowhammer fixes and generally a yolo auth system best described as "dangerous". You are better off using a well maintained project, that includes the CVEs^Wwarts.
It's a mistake to think that `doas` on Linux is the same as `doas` on BSD.
JoshTriplett · 5h ago
doas is not a compatible drop-in replacement for existing users.
dev_l1x_be · 4h ago
I did not claim that.
Here is my doas config:
cat /etc/doas.conf
permit nopass jane as root
It be read and understood without prior knowledge.
Sudo:
#ALL ALL = (root) NOPASSWD: C_ZFS
I have no idea what is going here, not sure what ALL means, why root is in (), etc.
778464636 · 4h ago
Neither is sudo-rs. From TFA:
> some features of the original sudo will not be implemented in sudo-rs if they serve only highly niche use cases
hedora · 5h ago
I wonder if there’s one that hardcodes a simple policy like “members of the wheel group can run any command with a password, and a 5 minute timeout”, but is also sudo command line compatible.
That’s what 99% of distros default to, and it’s simple.
badgersnake · 4h ago
For my limited use case, alias sudo=doas seems to work fine.
rbanffy · 2h ago
What are the implications of the license not being GPL?
Ubuntu continuously updates itself without permission, killing apps and losing previous state. You have the Javascript based Gnome window manager that is always bugging out. The Ubuntu packages, drivers and kernel are laughably behind Debian and even further behind mainline. Ubuntu continues to morph into something I don't believe in.
That all said, Rust is not a smoking gun for incorrect application logic. It could still happily incorrectly execute stuff with the wrong permissions or blow something up badly. I think it's also a bad idea to offer it as a drop-in replacement when clearly features are still missing since a long time [1].
[1] https://github.com/trifectatechfoundation/sudo-rs/issues?pag...
This side steps the issue which is "Does Rust help you make software more correct?" No one is arguing that Rust is perfect. There are plenty of bugs in my Rust software. The question is only -- are we better off with Rust than the alternatives?
> I think it's also a bad idea to offer it as a drop-in replacement when clearly features are still missing since a long time [1].
Your example is the Github issue page?
Look -- I agree that, say, uutils/coreutils missing locales may frustrate some users (although I almost never use them). But "close enough" is more the Unix way than we may care to realize. Ubuntu wants to lay claim to "the Rust distribution" and it's hard to blame them when Linux wants to lay claim to "the Rust kernel". But especially in this instance, because sudo is not POSIX (unlike locales which are). A distro is free to choose any number of alternatives.
Even with your explanation I don't think it fits here.
[1] https://en.m.wiktionary.org/wiki/smoking_gun
There's no valid reason cyber security people would take a well known idiom and repurpose it as you imply, and a quick Google suggests they haven't done this.
I tried the latest Ubuntu and it seems to be targeted at either containers or desktops. Everything I wanted to set up networking wise was a pain for my little non standard configuration.
Ended up wiping it and installing Debian instead.
As for this Rust thing, first question that comes to my mind is what features are missing from this new godly impervious to hackers by default implementation.
One of my former colleagues used to install Ubuntu servers. I replace them with Debian when I get the chance. I was already blacklisted for Snap, so I can't re-blacklist them for going uutils and sudo-rs, and that's sad (as in Bryan Cantrell's presentation).
What? Is this some snap thing because apt sure as hell doesn't do this without you configuring it explicitly.
The bigger problem is upgrading packages deliberately but being surprised by the results. My team's current favorite is the upgrade process itself suddenly having new interactive prompts breaking our scripts.
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!
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.
* 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.
Anybody who finds themselves using sudo is already well off the beaten path, by their own choice. There's nothing wrong with that.
So does your OS.
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.
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?".
Nitpicking, but I thought Android was the most widely deployed Linux OS around...
Bit like how tomato is technically a fruit but everyone knows that in the context of a supermarket it’s a vegtable
[1] because it doesn't abstract the hardware platform, doesn't multiplex hardware, nor protect software principals from each other https://www.youtube.com/watch?v=36myc8wQhLo&t=8m48s
Idk, just speculating to maybe get the thought process
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.
Linux is not a Unix https://en.wikipedia.org/wiki/Unix-like
I don't have a problem with it, specifically. Seems odd that they don't advertise it, though.
Somehow "maintainability" has never been something I'd ever associate with Ubuntu. Is it a reference to their source tree? That'd make a lot more sense than if they were referring to the OS itself.
run0 does not (and instead relies on systemd).
---
To answer your next question: setuid, while historic, is a bit weird, and is disabled in some environments, e.g. NoNewPrivileges.
If your bar is “I’ll tolerate such crap”, you may as well run your desktop session as root.
[1]: https://www.sudo.ws/security/advisories/
[2]: https://www.sudo.ws/security/advisories/unescape_overflow/
By all means, write a better, safer, smaller, more secure version of sudo, but don't have command be sudo or sudo-rs, name it something else.
This makes me wonder:
1) Would a hypothetical "sudo-lite" with these features removed lead to better security without a rewrite?
2) If these features are useful in the real world, will a Rust rewrite of sudo inevitably gain these features over time and end up with similar problems?
OpenBSD did this with their doas utility:
* https://en.wikipedia.org/wiki/Doas
That's not to say that it won't create other ones.
> In practice, there are few installations that use sudo-ldap. Most installations that use LDAP as a directory service and sudo have now opted for sssd, sssd-ldap and libsss-sudo.
> The Debian sudo team recommends the use of libsss-sudo for new installations and the migration of existing installations from sudo-ldap to libsss-sudo and sssd.
https://nvd.nist.gov/vuln/detail/cve-2021-3156
[1] http://github.com/uutils/
The Linux port has not been maintained for 3 years. Has unmerged rowhammer fixes and generally a yolo auth system best described as "dangerous". You are better off using a well maintained project, that includes the CVEs^Wwarts.
It's a mistake to think that `doas` on Linux is the same as `doas` on BSD.
Here is my doas config:
It be read and understood without prior knowledge.Sudo: #ALL ALL = (root) NOPASSWD: C_ZFS
I have no idea what is going here, not sure what ALL means, why root is in (), etc.
> some features of the original sudo will not be implemented in sudo-rs if they serve only highly niche use cases
That’s what 99% of distros default to, and it’s simple.