So I don’t even use systemd myself I run OpenRC. Yet honestly I find the idea quite intriguing, having the service manager (PID 1) invoke the command seems like a cool idea to me.
It’s not really a sudo alternative as much as it is another way of doing something similar.
Systemdeez nuts
Gentleman and scholar
As long as it’s not a mandatory switch, I can’t see any issue with this.
It’s the same drama as with the home directory replacement they announced and that no-one ever used.
homedisn’t exactly a home directory replacement, more of an extension. You can mix and match homed and normal home directories like you want (on a per-user basis at least, not within a single user). It does have some nice things, such as user-password based encryption of the home directory, so the password is required to unlock it (no admin access) or automatically using subvolumes on btrfs.user-password based encryption of the home directory, so the password is required to unlock it (no admin access)
That seems like a very niche feature given that it is only relevant if the admin isn’t the same person as the user but the admin would have to set it up and condemn themselves to hearing endless whining from users who lose their files when they forgot their password.
Let me introduce you to selinux.
In what way does selinux allow your users to lock themselves out of their own home directories in a way that the admin can not fix?
SElinux is a “global ACL.” You can stop root from doing anything you like with it. Usually by accident and without realizing it’s been done in my experience…
No, that is just not true. You can stop root from doing things without a reboot with SELinux but encrypting something with a password root does not know actually does stop them from doing it at all short of a brute force attack on the encryption.
In theory it isn’t mandatory, in practice you will see a lot of distros replacing it.
You think? Hardly anyone uses the built-in network stack or the homed thing.
Idk for the network stack, but for homed, I think it’s because it is up to the DEs to support it. As part of the Sovereign tech fund, GNOME is implementing support for it! I think this will be a great step forward for Linux desktop security when it lands
Yeah, that makes a lot of sense. Not needing the SUID bit on a complex tool is just a good idea. The simpler use cases can switch to
doas, the use cases that require complex configuration can switch to something likerun0, and the world of Linux is just a little bit harder to hack.I read the original mastodon post by the developer of run0 and I am still don’t understand what the problem with SUID is.
Whats an example of an attack that would work with sudo and doas (which also uses SUID) and not on run0?
Any code execution inside of a SUID binary basically becomes root access. That means that SUID binaries need a lot of security measures for everything they do. The more complex you make your SUID capable binary, the more work this adds, and the higher the probability that you’re introducing some kind of bypass vulnerability.
With sudo and to some extent doas, the process that should be in charge of vetting whether or not a user can become root/another user (and probably should only be doing that) is also parsing files, interacting with the network, possibly doing I/O on the filesystem. The binary is started as a user with limited permissions, but that user has full control of the binary’s environment.
With a root daemon (the one your system already needs if you’re running systemd in the first place), the binary that submits the elevation request can be as small as possible, and have no additional permissions. You can trick run0 into doing something, but that won’t give you root access, as polkit and other mechanisms actually decide if you’re root or not. If you’re not root, you’re not going to be able to seriously influence those daemons, even if you debug and monitor the memory of the application that’s communicating with them, or somehow manage to LD_PRELOAD some malware into it.
Take, for instance, CVE-2023–22809. This vulnerability allowed some users to write files with root permissions (think /etc/sudoers) when the low privilege user was permitted to only edit files on a whitelist, because rather than taking the root user environment variables, various sudo tools accepted the user’s environment variables (the ones you provide on the command line) to decide what editor to launch. This editor could (basically) be ‘nano /etc/passwd’ and when you sudoedit /etc/user/tool/file/here.conf (as specified in sido’s config), sudoedit would spawn an editor opening /etc/passwd instead.
In the daemon model of run0, the daemon would be the one evaluating its (root) environment variables and picking the editor. However, in sudo, the binary that allowed itself to become root, could also be directly influenced by the low privilege user, and its protections against tampering proved insufficient.
This entire class of attacks just isn’t viable when the binary the end user runs doesn’t have the ability to exert any control. All the important bits are on the “other side”, running as a different user, isolated from the low privilege side.
Thanks for taking the time to explain. I was trying to get my head around on how this works but could not understand much of it. A lot of people here are very much against systemd in all senses, but this sounds like a better approach. Even if it not done as systemd, makes more sense than checking files and getting elevated privileges for a scope and use guardrails everywhere
Agreed, this is a nice inclusion. I also hate sudoers with a passion - I already use
doasbut it’s not standard (in the Linux world anyway), but with systemd providing an alternative means that it’ll become a standard which most distros would adopt, and I hope this means we can finally ditch the convoluted sudoers file once and for all.I wouldn’t rely on distros adopting it as a default. systemd has a whole range of features, like network management, that many distros still use other tools for, like NetworkManager and netplan.
The thing with this is: its just a symlink to the
systemd-runbinary, which talks to PID1 to spawn new processes (in separate cgroups IIRC). Its one of the most fundamental parts of systemd. Even the debiansystemdpackage includessystemd-run.I haven’t checked the details yet, but surely this will need configuration to decide what users are allowed to use run0. The binary might exist, ready to be configured (the same is true for many systemd deployments that use alternative network managers!) but without configuration to match, I don’t think run0 will be usable for users that don’t already have root access.
it does its authorization with polkit (which IIRC defaults to allow all
wheelgroup members) and giving users that shouldn’t be allowed root access, root access, is not something you ever want. This is usually referred to as unauthorized privilege escalation. Also, it isn’t likesudodoesn’t need configuration.
How does doas differ from sudo?
Never heard of the former until now.
Essentially functionally stripped sudo, smaller in size than sudo. See also Pottering’s thoughts about the ecosystem
I admit, I’m not a big fan of putting more functionality into systemd (or just of systemd in general), but that is a well-reasoned argument for having sudo live in the init system.
Nice to see that Mastodon has the same problem as Twitter with people trying to use it for long-form blog posts for some godforsaken reason.
Makes sense considering people who moved from one micro-blogging service to another instead of giving up on the idea completely are probably the ones deeply committed to that flawed idea.
Blame the Mastodon team, if you’re not running a fork, you have to go into the source and adjust the character limit manually.
Nobody has to do it like this, Mastodon supports longer posts since other servers and clients support more, it’s seemingly just a choice from upstream.
doasis quite popular in the BSD world, and was ported to Linux a few years ago (via the OpenDoas project).For starters, it’s is a lot smaller than sudo - under 2k lines of code vs sudo’s 132k - this makes it lot more easier to audit and maintain, and technically less likely to have vulnerabilities.
Another security advantage is that
doasdoesn’t pass on the environment variables by default (you’d have to explicitly declare the ones you want to pass, which you can do so in the config).The config is also a lot simpler, and doesn’t force you to use
visudo- which never made sense to me,visudoshould’ve just generated the actual config, instead of checking it after the fact. Kinda like howgrubbyorgrub2-mkconfigworks. But no need for that complexity with doas.Eg, the most basic
doasconfig could just have one line in the file:permit: wheel. Maybe have another line for programs you want to run without a password, likepermit nopass dexter cmd pacman.Awesome. Thanks for the insight.
Surprised people aren’t moaning about systemd being too big already and still wanting to do more.
Those comments are here now, you can come check again 😅
😂
It’s too big!
That’s what somethin’ somethin’ said lastnight, Trebek! ;)
😂
SPoF !!! Ahhhhh we all dead
When does systemd stop? Linux without it is increasingly looking unlikely in the future. Are we not worried about it being a single point of failure and attack vector?
This isn’t a moan about the unix philosophy btw, but a genuine curiosity about how we split responsibilities in todays linux environment.
Systemd is a bit of a hassle to be rid off, but thankfully it’s not actually that hard, the hardest part I found was converting systemd services to whatever init system I use.
I wonder how many hours you sunk into that practicality-free, weird-philosopy-dependent project
Probably not much time, a lot of packages come with init scripts anyway, and they’re pretty trivial to write if not.
You can certainly argue it’s a philosophical choice, I’d say it’s more down to recognising the many poor architectural choices in systemd, rubbing agaist its many pain points and misfeatures and being alarmed at the size of the attack surface it exposes. I understand there is an effort underway to reduce the size and complexity of the main shared library to help address the last point, but just the fact that is necessary shows the scope of the problem.
Systemd is fine. If it wasn’t, most distros wouldn’t have switched to it years ago.
Let’s agree to disagree on that point. Redhat switched because they invented it, and so took all the RHEL derivative distros with them. Debian switched to prefer it after a rather contentious vote and so took all the Debian derivative distros, including Ubuntu, with them. That just leaves a lot of the smaller distros, most of which seem to have stuck with sysvinit or similar as far as I can see.
The arguments against systemd are very unconvincing but more importantly, there is zero evidence that they actually matter.
And it works.
Further, in order to represent this as a nearly unilateral decision you failed to mention that arch, centos, and opensuse all opted in independently.
And no offense but angry Internet randos arguing software philosophy will never convince me to disagree with the creator of the Linux kernel.
Linus Torvalds said:
“I don’t actually have any particularly strong opinions on systemd itself. I’ve had issues with some of the core developers that I think are much too cavalier about bugs and compatibility, and I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues.”
I obviously find the arguments against systemd more persuasive than you do, and that’s fine, it’s all open source and we can all make our own choices about it. My experience with it over the years has been, and still is that it vastly over complicates things that used to be simple, often the less commonly used parts just don’t work right (the automounter is a particular bugbear of mine, and few distros seem to use the network management component). The arguments do matter in practical terms as they directly impact how it works.
Of the distros you mentioned, centos is a RHEL derivative and so wasn’t independent, arch packages multiple init systems, but yes, I’d forgotten opensuse, and they seem to be firmly in the systemd camp.
I may be an internet rando, but I’m not actually angry, more just disappointed. I’d agree with Mr Torvald’s opinion that some of the design details are insane, but I think they are more fundamental than just ‘details’ as many are to do with the fundamental concepts around what systemd is and how it works. Linus can be a real dragon around changes to the kernel, but he’s always tended to be more relaxed about the layers above it.
That the developers of systemd are ‘much too cavalier about bugs and compatibility’ is surely clear to anyone who follows the relevant mailing lists and bug trackers, and should alarm everyone.
Gentoo, Slackware and Devuan can be used without svchost for linux.
They’ll only stop when they rebrand it to systemd OS.
Debian works fine without systemd too, there’s a page on the wiki on how to install without it, or remove it after the fact.
A lot of debs add services to systemd, do those just skip that part?
Gentoo, Slackware and Devuan can be used without svchost for linux.
https://nosystemd.org has a list for more choice for readers.
By this logic the Linux kernel is also a single point of failure and attack vector.
sudo isn’t going away, so does doas. run0 is just another alternative to use or not.
There are still distribution out there without systemd and if there ever won’t be any systemd-free distributions left and systemd would become a critical part of the Linux ecosystem, then it would get the same treatment as the Linux kernel with many professional maintainers.
@Olap
I agree. As someone who uses systemd on daily basis (I use Arch, BTW 😄) I really like it, but I am a bit worried about it being a single point of attack. Maybe just push doas as default instead? I never used doas but I watched few videos about it, so I guess it’s fine and probably better than sudo (less bloated).
Just my few cents.I don’t see how something would be inherently easier to attack if it is called systemd-foo instead of just foo. Attack surface and vectors do not depend on which project develops a particular tool.
SystemD will consume the entirety of Linux, bit by bit.
- In 2032, SystemD announces they’re going to be introducing a new way to manage software on Linux
- In 2035, SystemD will announce they’re making a display system to replace the ageing Wayland
- In 2038, the SystemD team announces they’re making their own desktop environment
- In 2039 SystemD’s codebase has grown to sixteen times its size in the 2020s. SystemD’s announces they’re going to release replacements for most other packages and ship their own vanilla distro.
- In 2045 SystemD’s distro has become the standard Linux distribution. Most other distros have quietly faded away.
- In 2047, SystemD announces they’re going to incorporate most of GNU into SystemD. Outrage ensues from the Free Software Foundation, which vehemently opposes this move.
- In 2048, Richard Stallman dies of a heart attack after attempting to clone SystemD’s git repo. SystemD engages in a hostile takeover and all resistance within the FSF crumbles
- In 2050, SystemD buys the struggling RedHat from IBM for $61 million.
- In 2053, most world governments have been pressured into using SystemD.
- In 2054, Linus Torvalds, fearing for his life, begins negotiations to merge kernel development into SystemD
- In 2056, the final message on the Linux kernel development mailing list is sent.
- In 2060, SystemD agents assassinate the CEO of Microsoft.
- In 2063, after immense pressure from SystemD-controlled human rights organisations, Arch developers discontinue development.
- In 2064, the remaining living Debian developers release the next stable version of their clandestine and highly illegal distro.
Debian already uses systemd.
Debian in many ways isn’t as slow-moving as people think.
For example, they moved to Wayland by default (for Gnome anyway) in 2019. A number of well-known distros likely won’t have that until 2025/2026 or beyond.
Sadly they’ve been dropping archs throughout the years, meaning they’re no longer the distro you can use to run on “anything” from a pi to a mainframe…
Doesn’t trixie still support like a dozen arches? I think one of the more recent deprecations was MIPS BE which is functionally obsolete in 2024, at least insofar as practically no one is using it to run a modern distribution.
Bookworm, Trixie, and Sid all currently support a total of 10 different architectures.
And looking through the Wikipedia article for Debian’s version history, most of the dropped architectures were functionally obsolete when they were dropped, or like the Motorola 68000, when support was added. (notable exceptions being IA-64 which was dropped 4 years before intel discontinued it, SPARC which is still supported by Oracle, and PowerPC.)
If your bar is “modern distribution” stick to Ubuntu.
If you want to maintain older hardware Debian used to be a go-to solution.
What’s the go-to solution now?
One way to notice a person has “systemd derangement syndrome” is by looking at how they write
systemd: if they write itSystemDthey are already in late stages of SDS and it isn’t curable anymore.Either that, or it’s a joke.
This is a script of Simpsons episode and Torvalds will actually die in 2058.
Probably the weirdest joke comment I’ve ever read.
I think you might want to recheck the ages of some of the people in your timeline, most of them aren’t that young anymore.
Yes, because it’s easier to take care of octogenarians than people who might actually put up a fight to having their laptop batteries replaced with a pipe bomb.
Thanks for that write up. Made my day! 😄
That comment was brought to you by an AI LLM. No one actually took the time to write that.
🥴
Nope, doesn’t have any of the hallmarks of an LLM and LLMs aren’t yet clever enough to produce original humor like that.
Dude if you made a movie or novel about this that would be awesome
When does systemd stop?
“systemd announces a repleacement module for the kernel”
HurD
Soon we will have to call it GNU/systemd/Linux
I mean it should kind of already be something like GNU/SystemD/X11/PipeWire/Linux, I guess.
It’s not like the GNU utils are the only massive integral part of the OS.
Nah. Replacing the kernel is probably planned for the next point release - it’ll just be GNU/systemd
Can we rename it GNUtriSystemD?
Systemd makes life easy. It also makes Linux more teachable. I like accessibility and don’t even mind this
I’m not on the systemd hate train by any means, but I don’t understand how this is any improvement over
pkexecI don’t understand how this is any improvement over pkexec
That has the same problem as
sudo: the SUID bit is set for it.The fact that
run0uses polkit is more of a byproduct that this kinda authentication is already done with polkit all over the place in systemd. You can have individual subcommand accessible to different users (for example everyone cansystemctl status, butsystemctl rebootneeds to be in thewheelgroup) which is why its generally used within systemd already. And it wouldn’t surprise me if again you can do it with this as well, limiting what commands can unconditionally run, need prompt or are completely blocked.I’m unclear from the documentation, does pkexec work under non-GUI contexts?
As long as you have polkit setup to work in terminal sessions, yes. This is pretty standard these days, though not particularly widely used.
hard disagree. life with plain text logs and daemon init scripts was so easy and nice. But we can’t have nice things…
Those hacked together system-specific bash scripts were shit. Having a standard way of creating, starting, ensuring restarts,and logging services is so much better.
You can still get all the plain text logs you like.
How do you get plain-text logs instead of the garbage binary format that
journalctlforces on you?By configuring journald to forward messages to syslog as is the default.
“forces on you” 🙄
Edit: Systemd has been around for 14 years. Did you never think to google this?
Set ForwardToSyslog=yes in journald.conf and install a syslog daemon. Also optionally Storage=volatile (I wouldn’t set Storage=none unless you want systemd to no longer show you any logs anywhere including in systemctl status because I assume it will do that)
Thank you!
Definitely reads like a Microsoft answer, seems so much easier than just reading text
Those hacked together system-specific bash scripts were shit.
With a different feature set per script as well. The systemd service files have often been pushed upstream.
Pretty sure people liking those scripts never really tried dealing with them across distributions. Though this just rehashes things that were said when distributions decided if to switch to systemd. Still the same strange claim that those scripts are somehow easier. It wasn’t, it is also way easier to package a systemd file from upstream than to maintain that stuff within a distribution.
You know what’s nice? Being able to sit down at any Linux distro and being able to set up and configure services without Googling how to use that particular distro’s init system.
But it’s so unbearably slow.
Me when my computer that has a typical uptime of 37 days boots up in 7 seconds with systemd instead of 5.5 seconds with runit: 😡😡😡😡
Lmao yeah exactly
Or as I’ve taken to calling it, GNU+systemd+Linux.
In the old days, it was Emacs trying to do everything. Now, it’s the SystemD.
That was so bad that vim users needed to make nvim to handle Emacs envy, and every modern ide tries to do the same in worse ways.
(Not trying to start a holy war, I use both)
This is great. Not having the attack surface of
sudo(and not even being a SUID binary) certainly are great additions.And I hope people realize that
systemdis not one large thing, but a (large) collection of tools.This is great. Not having the attack surface of sudo (and not even being a SUID binary) certainly are great additions.
And I hope people realize that systemd is not one large thing, but a (large) collection of tools.
XZ-utils rings a bell ? It was among others Debian wanting to pull in part of a systemd tool into openssh and that almost turned into a world wide disaster :(
I didnt understand that sentence. Is that what you meant?
Among other things, Debian wanted to integrate a part of the systemd tools into openssh, which almost led to a worldwide catastrophe
xz is not part of systemd or openssh afaik.
You didn’t follow the XZ-utils story ? The malicious actor worked for years on that XZ backdoor that targeted the fact that some Linux distributions were modifying their openssh package to enable systemd notifications.
Ok true, it was a systemd dependent issue. But it only makes sense to have those notifications. The problem is dependency on small hardly maintained products, which systemd will improve by centralizing it.
And where do maintainers for the new parts of systemd come from? The larger systemd grows the more parts of it will be neglected. Also in regard to people checking commits, opening up doors for exploits like the one in xz.
I dont know but for sure has pros and cons
But it only makes sense to have those notifications.
Maybe in your mind it makes sense. Going for ease of use rather than security is not something that OpenBSD would quickly do. If you read some more about what “jwz” has to say about all the screensaver bugs in Linux, like here : https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition and realize what a mess that Linux maintainers are making again and again, and then have a look at Debian and their packaging of xscreensaver. Guess what ? Debian added some systemd thingie to xscreensaver. 🤯
I like Debian since a long time and I use it. But the tinkering of Debian package maintainers and always wanting to do things the Debian way is not something I am always very pleased with. Remember the OpenSSL Debian fiasco ? That shows a problem with Debian which may still exist. Too many packages, not enough maintainers with enough spare time, and no coherent team work of a security team.
Kinda feels like writing a script that implements the
sudoCLI but callspkexecwould be an easier way to do it. Given that so many systems already come with bothsudoandpkexec, do we really need yet another option?The point of this is to implement some form of privilege escalation without the SUID mechanism.
sudo,pkexecanddoasare all SUID.
I’ve had to scroll down eight pages to find a post that seems to actually address the good points raised in the article.
The attack surface will be a systemd daemon running with UID=0 instead, because how else are you going to hand out root privileges?
So it doesn’t really change anything to the attack surface, it just moves it to a different location.
That already exists.
systemd-runis already available today. So the attack surface would be smallerNot really, because you’re now going to make it do more, i.e. incorporate the functionality of sudo and expose it to user input. So unless you can prove that the newly written code is somehow inherently more secure than sudo’s existing code, the attack surface is exactly the same.
that
systemdis not one large thing, but a (large) collection of tools.Who don’t work without Systemd. And Systemd can’t coexist with tools in the same repo doing the same job in a portable way.
Right. That reminds of the time I was visiting a friend who had broken his Linux computer (No, not “apt-get remove --purge systemd” but they did something slightly similar). When I booted from a live Linux, used chroot and wanted to use configure networking : FAIL because systemd was … not running. As he had no Internet because of his broken machine this caused some delays in fixing this but we got the job done eventually.
Just like gnu utils.
But gnu utils work on BSD and others, while Systemd is Linux only.
This is why people don’t like systemd…
Systemd monolith - worst thing to have ever happened to Linux
Wayland monolith - best thing to have ever happened to Linux
Oh you had me going in the first half. Sly devil you. Wayland still doesn’t work on the fleet of equipment we have.
I think wayland has potential but in it’s current state it’s just half baked. Once more protocols get merged,
maybe in a decades timeWayland should be quite flexible and robust.More like over baked but still only half done.
It does have potential. I think anyone denying that is simply wrong. the issue with wayland is purely how slowly it moves and the fragmentation. Now the fragmentation is actually in large part due to how slowly it moves. There are numerous WIP protocols that will greatly decrease fragmentation when all are merged.
I can’t wait because it seems like it will happen in the short future of one or two decades xD
That’s how I feel as well. IMO it’s ridiculous that Fedora wants to remove xorg completely from the repos in the next version.
It is ridiculous. Nothing like says f you to a large percentage of your user base like pushing out a solution that doesn’t work for them.
The wildest thing is that current xorg package is maintained by the community and they’re still removing it completely because “xorg is taking up too much dev time”.
If they had named it systemd-x11 people would hate it.
hey, many of us dislike both equally! (specially the push to become the only alternative)
Wayland monolith
There seems to be misunderstanding about what Wayland is.
Wayland is set of protocols. They are implemented by wayland servers (compositors) and wayland clients (applications) themselves. There is no single “wayland binary” like in the X11 days. Servers or clients may choose to implement or not implement a specific protocol.
X11 is a protocol too. Xorg is the binary you are talking about
They’re also all shit and dysfunctional as hell. Xorg forever. Systemd good too.
MacOS 7 forever, in the same way
I think what they meant is that there are people that think: “Wayland is too fragmented, there should be 1 ‘Wayland Compositor’ and the rest should be window managers”
Nope, I meant that the wayland compositors are inflexible monoliths that are so tightly integrated into a DE that they can’t be replaced. Xorg might be bloated, but it follows the UNIX philosophy closely enough that each part of the stack above xorg can be trivially replaced.
I guess my interpretation was too charitable.
Nothing in the protocol prevents you from splitting the server from the window manager, just everyone implementing the wayland server protocol didn’t see any benefit in splitting it out.
Wayland is set of protocols.
Oh my god! It’s like hearing the same on hold greeting again and again. WE KNOW!
Sure, but that doesn’t change the fact that Wayland compositors are forced to be inflexible monoliths that need to be so tightly integrated into a DE that they can’t be replaced.
In xorg the server, wm, and compositor all do their own thing and can be replaced trivially. It took me like 5 minutes to replace xfwm4 with i3, and that included the research.
Not that I’m opposed to a better sudo alternatives, but I find it rather ironic that one of the reason stated is the large attack surface, considering systemd is a massive attack surface already.
This isn’t exactly a “new” attack surface, so removing the attack surface that
sudo(and alternatives) is, is probably a net positive.That attack surface is not vanishing. It’s would be relocating the same attack surface to something that might have an xz library in memory.
As Microsoft and Poettering intended.
- The attack surface is there either way, this is just functionality repackaged that existed already before (
systemd-run, which is calling into PID1) - all compression libraries (actually most libraries at this point) are
dlopened on demand (which was planned even before the attack, which is speculated that the attack was accelerated in timeline because he was on a timer before the change was released)
- The attack surface is there either way, this is just functionality repackaged that existed already before (
Maybe that could be a good thing, but only if the distros do not include sudo by default, the fact to have one thing to update to update more things is good in the security side! If it’s well implemented I’m okay with it
Dudes trolling, right?
new sudo vulnerabilities? how exciting!
E: read the article, I guess that is part of the reason for the proposal. interesting
