this post was submitted on 30 Apr 2024
324 points (95.8% liked)

Linux

48031 readers
1047 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

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] nifoc@lemm.ee 39 points 6 months ago (5 children)

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.

[–] SpaceCadet@feddit.nl 31 points 6 months ago (1 children)

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.

[–] Kwdg@discuss.tchncs.de -1 points 6 months ago (1 children)

That already exists. systemd-run is already available today. So the attack surface would be smaller

[–] SpaceCadet@feddit.nl 6 points 6 months ago

Not 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.

[–] MonkderDritte@feddit.de 17 points 6 months ago* (last edited 6 months ago) (2 children)

that systemd is 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.

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.

[–] atzanteol@sh.itjust.works 9 points 6 months ago (1 children)
[–] MonkderDritte@feddit.de 3 points 6 months ago

But gnu utils work on BSD and others, while Systemd is Linux only.

[–] lemmyreader@lemmy.ml 4 points 6 months ago

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.

[–] lemmyreader@lemmy.ml 3 points 6 months ago* (last edited 6 months ago) (1 children)

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 :(

[–] boredsquirrel@slrpnk.net 14 points 6 months ago (1 children)

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.

[–] lemmyreader@lemmy.ml 10 points 6 months ago (1 children)

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.

[–] boredsquirrel@slrpnk.net 0 points 6 months ago (2 children)

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.

[–] Macros@feddit.de 3 points 6 months ago (1 children)

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.

[–] boredsquirrel@slrpnk.net 2 points 6 months ago

I dont know but for sure has pros and cons

[–] lemmyreader@lemmy.ml 1 points 6 months ago* (last edited 6 months ago) (1 children)

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.

[–] boredsquirrel@slrpnk.net 1 points 6 months ago

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?

[–] lengau@midwest.social 2 points 6 months ago (1 children)

Kinda feels like writing a script that implements the sudo CLI but calls pkexec would be an easier way to do it. Given that so many systems already come with both sudo and pkexec, do we really need yet another option?

[–] chameleon@kbin.social 3 points 6 months ago

The point of this is to implement some form of privilege escalation without the SUID mechanism. sudo, pkexec and doas are all SUID.

[–] digdilem@lemmy.ml 2 points 6 months ago

I've had to scroll down eight pages to find a post that seems to actually address the good points raised in the article.