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.
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.
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.
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. But especially in this instance, because sudo is not POSIX (unlike locales which are). A distro is free to choose any number of alternatives.
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".
Entirely untrue. It may happen, but there is zero consensus to port Linux to rust. Not even the tiniest bit.
There is a lot of embedded knowledge in existing implementations, Rust deals with just one small class of bugs but drops a lot of this knowledge in the process.
I would generally be in favour of just introducing better memory management to C/C++ and hard enforcing it in particular repositories.
It does default to installing security updates automatically. However, this is completely configurable.
It isn't reasonable to have different default behaviour - otherwise the majority of users would be vulnerable from a security perspective.
If you want different behaviour, just configure it as you wish.
> The Ubuntu packages, drivers and kernel are laughably behind Debian and even further behind mainline.
This just isn't a reasonable description of reality.
Unless you're referring to an Ubuntu LTS, in which case, of course it is: that's the entire point of Ubuntu LTS, and Ubuntu users have the choice of using the six monthly non-LTS releases if they want more up-to-date packages, which Debian users do not have.
Man, but have you personally tried to disable it?
Did you stop apt-daily.service apt-daily.time apt-daily-upgrade.service and apt-daily.timer? Did you repeat the same but masking and disabling those services. Don't forget to repeat that for unatended-upgrades.service. Even after that whenever our CI fails an apt-get we have a pstree output to figure out what other dark pattern canonical came up with.
This whole debacle made me consider RedHat for my next install, and I use Ubuntu for almost 2 decades. It became unreliable in servers.
Dont get me started on the lack of security updates on "multiverse" packages which starts to include more and more packages and thus LTS means less and less. This is not innocent but so you buy Ubuntu One.
A better default behaviour would be to alert the user and allow them to choose to indefinitely defer by "accepting the risk". Some setups, rightfully or wrongfully, have a very long running time and cannot be restarted.
> If you want different behaviour, just configure it as you wish.
I'm not sure if it changed, but they made it extremely difficult on purpose. You can stop snap from updating, but then lots of other things also break.
> This just isn't a reasonable description of reality.
It's my experience with packages I use.
What? Is this some snap thing because apt sure as hell doesn't do this without you configuring it explicitly.
There's no control of when snaps update, Ubuntu has explicitly said they will never add this.
There was no way to disable snap auto-updates until just last year(-ish?) when Firefox finally announced they would no longer support snaps and started telling people how to tear them out and replace them with native packages or Flatpaks. Low-and-behold, Ubuntu suddenly got the feature to disable automatic snap updates. After saying explicitly they would never allow it for years, and telling high-uptime users to instead block snap daemon network access via the firewall to avoid it.
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've never seen this happen and I've run Ubuntu in production for years. Apt does not auto-update unless it's configured for unattended upgrades — and both Debian and Ubuntu allow you to configure unattended upgrades in apt. And unattended upgrades via apt should not kill running user processes or cause data loss.
The Ubuntu packages, drivers, and kennel are laughably behind Debian.
This is just plain wrong — even for the steelman argument of Debian unstable or testing, which are not intended for general use. Debian unstable and testing are on kernel 6.12. Ubuntu 25.04 is on kernel 6.14.
Debian stable, meanwhile, is on 6.1. Ubuntu has the far more-recent kernel.
I don't know what you mean by "drivers" — there aren't separate drivers on Linux from the kernel; they're shipped in the kernel. Ubuntu's are also more recent than Debian, since the kernel version is more recent.
With respect to packages, obviously I can't check every package version, but e.g. coreutils in Ubuntu are on 9.5, released in March 2024; systemd on Ubuntu is a version released this year (and until last month Debian unstable and Ubuntu were identical); gcc is identical; etc. While Ubuntu occasionally lags Debian unstable, it's not by much.
If you compare to actual Debian stable, it's not even close. Debian stable is ancient.
And ultimately... Why are you using Debian unstable? It's called "unstable" for a reason. It receives basically no testing. Even the "testing" version is more stable, and that's not intended to be stable at all and doesn't necessarily receive security updates. Ubuntu is less-stable than Debian stable, but far more up-to-date; Debian testing is less-stable than Ubuntu... And usually still not even as up-to-date. Debian unstable is basically untested; if you want that you'd be better served by a rolling release distro like Arch where the packages are going to be way more up-to-date anyway.
The Debian wiki cautions against treating unstable or testing releases as general purpose, so I truly don't think even this steelman is viable. [1] In fact, they refuse to even call Debian unstable a "release" since there are no release practices associated with it and the code is effectively untested.
Ubuntu is nowhere near my favorite Linux distro, but claiming it's more out of date than Debian is just FUD.
Debian is very very stable — at least, Debian stable is — and people love it for that. But the tradeoff is that everything in it is ancient. If you want something that's like Debian, but more up-to-date but slightly less stable — that's Ubuntu. If you want a rolling release, that's Arch. (And of course, there are even more-different distros like NixOS or ostree-based ones; there's the Red Hat universe of RHEL and the closer-to-bleeding-edge Fedora; etc etc.) Using Debian unstable is either a magnanimous act of sacrifice in order to help test future Debian versions, or it's self-harm.
Personally if I wanted to use a Debian-derivative on the desktop, though, I'd probably use System76's PopOS, which is basically a cleaned-up Ubuntu with some nice GNOME extensions. I'm more curious in the future to try out ostree-based distros, though, like the various Fedora Atomic ones, since they have nice rollbacks without the user-facing complexity of NixOS.
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.
Ubuntu seems to find it necessary to always invent some new way of doing a standard thing. Like how they use netplan for networking, a tool they invented themselves for a task that already has industry standard options available, is missing basic features those alternatives have, and adds nothing the alternatives don't also have (including any better usability). They do this all the time, and have to eventually be dragged into the modern era when they finally get sick of having no community support for their one-off inferior tool.
In particular I'm just waiting for snaps to finally die. But at least that has some technical possibilities the alternatives don't, they just aren't functionally available in snaps yet. In another 20 years, if Ubuntu keeps at it with their unconfigurable, hardcoded, private snap registry and slow limited advancement snap portals-equivalent implementation, they might even have half as much functionality and packaged tools as Flatpak current has today.
---
If you want a decent server, Debian is a better option, even though they have some finnicky choices, and its enough like Ubuntu you might have some cross-ober familiarity. Some of the old standbys like Fedora aren't good options because of their frequent update schedule and lack of long term support, but there are also some very good niche options if you can dig a lot more.
Also worth noting: if you want to keep the server working, you should plan on pretty much everything being in containers. It adds some complexity to what you're doing, but keeps each little experiment isolated from the others and avoids polluting the global system.
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 famous talk).
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
What issues did you have with snap packages?
I am not aware of any problems with snap packages.
They have some pretty nice features compared to traditional packages:
https://snapcraft.io/docs/get-started#p-19156-connect-an-int...
If snap packages have caused problems for you, what were the problems?
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
[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
I don't have a problem with it, specifically. Seems odd that they don't advertise it, though.
[1]: https://www.sudo.ws/security/advisories/
[2]: https://www.sudo.ws/security/advisories/unescape_overflow/
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?
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.
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.
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.
- https://github.com/Duncaen/OpenDoas/issues/106
- https://github.com/slicer69/doas/issues/110
I have a hard time recommending doas over sudo on Linux when the issue has been fixed in sudo but not in doas.
Here is my doas config:
cat /etc/doas.conf
permit nopass jane as root
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.