What you’re refering to as Linux, is in fact, Systemd/Linux, or as I’ve recently taken to calling it, Systemd + Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning Systemd system made useful by the Systemd corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX
🤣
Thanks to BSDs we have sane alternatives :)
Soon we will have to call it GNU/systemd/Linux
Nah. Replacing the kernel is probably planned for the next point release - it’ll just be GNU/systemd
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.
Or as I’ve taken to calling it, GNU+systemd+Linux.
deleted by creator
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.deleted by creator
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 guess the other question is if some tools the distro provides might switch to supporting it by default. For example on Arch there is
makepkgthat should never be executed as root, but does internally call some things with elevated privileges (mostlypacmanto install and remove packages). Currently it checks forsudoand if not falls back tosu, but maybe it might be worth considering changingsuforrun0if its guaranteed to be there.deleted by creator
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.
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.
Essentially functionally stripped sudo, smaller in size than sudo. See also Pottering’s thoughts about the ecosystem
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.
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.
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.
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.
- 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 (
I’m no Linux expert, but I’ve never had any problems with sudo, it just works. Shouldn’t systemd have higher priorities on their mind? This feels like change for the sake of change. And if this does happen, I sincerely hope that it just works, like sudo.
I think the article (or more Lennart Poertting post) explains it quite nicely. The problem with sudo is that the sudo binary itself has the ability to gane elevated privileges which is a potential attack surface
deleted by creator
feature creep
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.
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.
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.
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.
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.
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.
Oh, it’s gonna use polkit. Sudo bloat is a grain of sand compared to polkit.
Why people want to replace sudo with polkit? Visudo is no near as obscure as configuring polkit.
I hope distro maintainers don’t follow this.
…is
pkexecnot good enough already as a polkit based sudo replacement? Why would one need to systemd-ify that?First thing I do with any new desktop installation is disable polkit prompts.
Fuck having to enter my password every time I want to do something.
Hey uh can I get your IP address real quick? I have a strong suspicion your philosophy extends to your network ports.
You’d be wrong about that.
Edit: he just downvotes me instead of admitting he’s wrong about his assumption, lol.
I just treat polkit as “set it and forget” kind of thing and leave it on defaults, I’d rather spend my time on something more important
Systemdeez nuts
Gentleman and scholar
I honestly started out not liking systemd at all, mostly due to the reports that it did waaay to much, but nowadays, I like the concept.
It is basically officially moving daemon management from a script-based approach to a table/database-based approach. That improves static analyzability, therefore increasing clarity, and probably even performance.
I agree that we should abandon scripts and move towards declarative software management, and abandoning
sudofor a more declarative system seems like a good step to me.Surprised people aren’t moaning about systemd being too big already and still wanting to do more.
It’s too big!
SPoF !!! Ahhhhh we all dead
There’s a rewrite of sudo happening in rust, but he wants to throw out the SUID idea altogether?
when invoked under the “run0” name (via a symlink) it behaves a lot like a sudo clone. But with one key difference: it’s not in fact SUID. Instead it just asks the service manager to invoke a command or shell under the target user’s UID. It allocates a new PTY for that, and then shovels data back and forth from the originating TTY and this PTY.
That sounds like opening up the door to what windows is doing UAC and the wonderful vulnerability that the GOG Launcher had for privilege escalation.
I’m not a security researcher, but giving arbitrary users the ability to tel PID 1 to run a binary of the user’s choosing is… probably not what Pottering is suggesting, but opens up to such vulnerabilities. And if it’s written in C/C++ my trust is further reduced.
Giving users access to PID1 running binaries, giving users access to the kernel running binaries as root, I don’t see much difference. SUID was notorious in the past for being leaky, it only ended when distros got serious about fencing use of it in, giving it only to programs actually needing it, making sure that they drop privilege properly, etc.
If anything I’m in the PID1 camp because it’s more microkernely. But in any case broader userspace shouldn’t really care about the mechanism, only have an API to do it and that API being a bit in the file permissions is soooo 1960s.
And if it’s written in C/C++ my trust is further reduced.
Do you trust Linux? Because if so, have I got news for you.
Wait until they hear the language used to implement OpenBSD. Imagine being one of the authors of seL4 encountering a member of the rust cult.
The meme is becoming a reality. Systemd really is going to try to be everything lmao
AlwaysHasBeen.jpg
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.
I’m not surprised. Not surprised at all. (scope creep)
