How long before humans are systemd compatible?
Run0, a systemd based alternative to sudo, announced
141–150 of 902 posts
Re: Run0, a systemd based alternative to sudo, announced
#142Earlier quoted context omitted.
> But what makes me really upset is this completely unexplainable need to make everything part of one particular init system. There is absolutely no reason to tie your new sudo replacement to systemd. Absolutely none. The systemd developers are tying it to systemd because they are systemd developers. If somebody else made something like this, it wouldn't be tied to systemd. But somebody else hasn't made something lik…
>The systemd developers are tying it to systemd because they are systemd developers. What? Literally every single other group of software developers has managed to create two projects. Even Microsoft can do it.
GNU didn't. Why should Systemd?
Re: Run0, a systemd based alternative to sudo, announced
#143Earlier quoted context omitted.
Let me get this right: you see an article on a new thing, which you have no problem with, but have an angry rant in the comments section anyway? And now you're baffled by people's reaction to that? I'm not sure there's much point engaging further, I hope you have a good rest of the day.
No, I think the systemd project shouldn't exist. I have no problem with someone writing a sudo replacement. Do you understand the difference?
Do you also think the GNU project shouldn't exist? If not, what's the difference?
Re: Run0, a systemd based alternative to sudo, announced
#144Earlier quoted context omitted.
LZMA is a widely used compression protocol. The kernel uses it. xz - the compression tool that was affected gets used by the kernel build makefiles - they reference it in the build docs https://docs.kernel.org/staging/xz.html . It's absolutely fair from systemd to have this dependency and to use the trusted library that the most fundamental part of the underlying OS uses. It was purely the attackers choice to leverag…
Your speculation on what is right and what was fair is of no consequence to me. Their error was not simply using a compression library, it was creating a large central point of failure. If Systemd was smaller, it would not have caused this error. By being large, it made itself vulnerable. It made itself a target. It made other software insecure. These facts are inescapable. And you cannot justify this by simply sayin…
Why is this an argument specifically against systemd, rather than all large software projects?
Linux kernel, gcc, glibc - all bundle "a large amount of functionality under a single system" - does this make their design fundamentally flawed as well?
Re: Run0, a systemd based alternative to sudo, announced
#145Earlier quoted context omitted.
First, getting rid of setuid (I guess you'd have to get rid of the whole thing, not just the permission bit) is not the same as making systemd an integral part of the OS. Second, when even the package maintainers can make such "trivial" mistakes, something is wrong. You'd expect a component such as systemd to be much more trustworthy than some random library. I'm not arguing against systemd, just that it seems to gro…
If it was "obviously" broken why was the xz backdoor such a shock to everyone? Do you personally audit the library dependencies of every tool you run, including core servers that come with your distribution? I think people don't do this. Also, even before the backdoor was discovered, the systemd team were making libxz be dynamically loaded only in the cases where it was needed which would have killed the backdoor dea…
The point is that (even) the systemd maintainers do not vet their dependencies. As an attack vector, it is the (second?) highest level, yet they did not assume the responsibility. Everybody silently assumed they did, hence the shock.
> Claims that systemd has bad security have to explain why it was already implementing practices ...
No, they don't. It doesn't take away the fact that they did not check xz, and probably only few of their other dependencies.
Re: Run0, a systemd based alternative to sudo, announced
#146This is very interesting, can somebody explain what this is and how it's different from executing through sudo? The LWN post links back to Lennart's Mastodon which in turn is a big pile of toots (ugh) in the wrong order
Re: Run0, a systemd based alternative to sudo, announced
#147Uses polkit. run0, which behaves like sudo, but works entirely differently and is not SUID. Run0 asks the services manager to create a shell or command under the target user’s ID, creating a new PTY, sending data back and forth from the originating TTY and the new PTY.
How hard would it be to create a program to send a signal to polkit "impersonating" run0 and obtains a root shell? :)
Re: Run0, a systemd based alternative to sudo, announced
#148This will be great. We can finally deprecate sudo on systemd systems. Then we should be able to deprecate PAM, setuid bit, etc.
Re: Run0, a systemd based alternative to sudo, announced
#149Earlier quoted context omitted.
If it was "obviously" broken why was the xz backdoor such a shock to everyone? Do you personally audit the library dependencies of every tool you run, including core servers that come with your distribution? I think people don't do this. Also, even before the backdoor was discovered, the systemd team were making libxz be dynamically loaded only in the cases where it was needed which would have killed the backdoor dea…
The point is that (even) the systemd maintainers do not vet their dependencies. As an attack vector, it is the (second?) highest level, yet they did not assume the responsibility. Everybody silently assumed they did, hence the shock. > Claims that systemd has bad security have to explain why it was already implementing practices ... No, they don't. It doesn't take away the fact that they did not check xz, and probabl…
Nobody was silently assuming the systemd maintainers were reviewing the source tarballs of every dependency for obfuscated back doors.
Re: Run0, a systemd based alternative to sudo, announced
#150> One could say, "run0" is closer to behaviour of "ssh" than to "sudo", in many ways.
This is an interesting offhand comment. You could implement a very similar tool by SSHing to localhost.