It has some advantages. It can be configured with simple text files and normal filesystem permissions. The sshd code is mature and has a proven record of good security. It doesn't add yet another thing to systemd that has no business being part of systemd.
I really don’t get why an alias to something that would be in systemd anyway (that’s all run0 is, an alias to systemd-run) would be an issue. Is systemd-run problematic or something?
Sure, the project is already bloated with so much complexity that what's the harm in adding a little more? If you're genuinely confused about it, see the entire rest of the Internet for details.
The problem is that they’re trying to frame it as a better replacement for sudo when it’s really not.
In some respects, it’s safer by not using a setuid binary. In other respects, it massively increases the surface area by relying on the correctness of three separate daemons: systemd, dbus, and polkitd. If any one of those components are misconfigured, you risk an unauthorized user gaining root privileges.
With sudo, the main concern is the sudo process being exploited through memory safety bugs since it runs at root automatically.
Don’t get me wrong, sudo has a lot of stupid decisions and problems. There’s a ton of code in sudo for features that almost nobody uses, and there’s bound to be bugs in there somewhere. It needs to be replaced with something simpler, but run0 is not that.
Thank you for a non-hand-wavy response! I’m not entirely sure I agree, depending on more libraries doesn’t have to be an issue if they’re well designed and frequently used elsewhere, no? Is the implication here that systemd isn’t well designed?
In any case, would you say sudo is the best we have for temporary root elevation at the moment? I haven’t really heard of an alternative apart from doas.
lambalicious@lemmy.sdf.org
on 24 Jun 03:58
collapse
alias run0=sudo
(not really; I’d rather not introduce an alias or any sort of symbolic behaviour that would teach me to expect that systemd crap is available on a system. The less you rely on it, the better)
velox_vulnus@lemmy.ml
on 23 Jun 16:50
nextcollapse
Not relevant to the topic in discussion, but I like the simple site design. Someone really needs to work on the long-ass page - at least limit to five blogs on main page and add the pagination in a separate blog page. Scrolling was a weird experience.
Seems novel. But from a security aspect, if OpenSSH has security vulnerability that allows an unauthenticated user to login, via whatever means, once you are in the system as a non-privileged user, you are now free to use the same vulnerability to get root.
Basically this exercise is like using two locks that have the same key to open them. If the same key opens them, then a weakness in one, is now a weakness in the other so why bother with two identical locks?
threaded - newest
A better implementation than
run0.Why?
It has some advantages. It can be configured with simple text files and normal filesystem permissions. The sshd code is mature and has a proven record of good security. It doesn't add yet another thing to systemd that has no business being part of systemd.
I really don’t get why an alias to something that would be in systemd anyway (that’s all run0 is, an alias to systemd-run) would be an issue. Is systemd-run problematic or something?
Sure, the project is already bloated with so much complexity that what's the harm in adding a little more? If you're genuinely confused about it, see the entire rest of the Internet for details.
The problem is that they’re trying to frame it as a better replacement for sudo when it’s really not.
In some respects, it’s safer by not using a setuid binary. In other respects, it massively increases the surface area by relying on the correctness of three separate daemons: systemd, dbus, and polkitd. If any one of those components are misconfigured, you risk an unauthorized user gaining root privileges.
With sudo, the main concern is the sudo process being exploited through memory safety bugs since it runs at root automatically.
Don’t get me wrong, sudo has a lot of stupid decisions and problems. There’s a ton of code in sudo for features that almost nobody uses, and there’s bound to be bugs in there somewhere. It needs to be replaced with something simpler, but run0 is not that.
Thank you for a non-hand-wavy response! I’m not entirely sure I agree, depending on more libraries doesn’t have to be an issue if they’re well designed and frequently used elsewhere, no? Is the implication here that systemd isn’t well designed?
In any case, would you say sudo is the best we have for temporary root elevation at the moment? I haven’t really heard of an alternative apart from doas.
Just for my own understanding, if any of those are misconfigured, do you not anyway have a big security problem already, regardless of run0?
.
…I feel like openssh has a much larger attack surface than a simple binary.
If you’re going to this extent already, you may as well jump on the run0 approach systemd is introducing.
oh no, I can hear rumbling
Right. This is just trading one set of security pitfalls with a second, much worse set of security pitfalls.
.
That’s a lot of bullshit to post.
It’s a copypasta, most probably
obviously a troll. And a stupid one at that
tl;dr; ?
alias run0=sudo(not really; I’d rather not introduce an alias or any sort of symbolic behaviour that would teach me to expect that systemd crap is available on a system. The less you rely on it, the better)
Not relevant to the topic in discussion, but I like the simple site design. Someone really needs to work on the long-ass page - at least limit to five blogs on main page and add the pagination in a separate blog page. Scrolling was a weird experience.
Seems novel. But from a security aspect, if OpenSSH has security vulnerability that allows an unauthenticated user to login, via whatever means, once you are in the system as a non-privileged user, you are now free to use the same vulnerability to get root.
Basically this exercise is like using two locks that have the same key to open them. If the same key opens them, then a weakness in one, is now a weakness in the other so why bother with two identical locks?