324
Systemd wants to expand to include a sudo replacement
(outpost.fosspost.org)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 30 Apr 2024
324 points (95.8% liked)
Linux
48721 readers
2365 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
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.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.
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.
I think Chimera was it (?) which tried to have Systemd and Runit and others in the same repo. With lots of wrappers and shims. Not because of Runit & co.
Just like gnu utils.
But gnu utils work on BSD and others, while Systemd is Linux only.
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.
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?
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
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.
You are talking about Debian holding back random packages for stability. This is of course not very cool but it needs to be tested.
I am very much in favor of isolate app environments controlled by upstream devs, containerized and with a permission system. The system is made by the distro, and can be stable and very tested, and the apps are simply isolated and made by upstream.
There is no xscreensaver on Wayland and I think this will not come back?
I've had to scroll down eight pages to find a post that seems to actually address the good points raised in the article.
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.