Oh, man. The 2000s called and they want their integer overflow bugs back.
"unprivileged users with UID > INT_MAX can successfully execute any systemctl command"
@paco systemd: the gift that keeps giving.
Systemd is, in this case, apparently overriding other system permission controls because the auth system they are using said it was OK.
Reducing trust would seem to be a minimum necessary response here, but instead the response is "not a bug in our code, not our problem".
@RandomDamage @jerry @paco systemd is doing nothing with authentication here. Again: It is a polkit bug. Polkit is the authentication system that accepts that.
I don't know the details, but In guess polkit executes the command, not systemd.
And this is obviously not their bug, so it is absolutely okay, to close this as "this is a polkit bug".
If you know more details about the architecture or what needs to be changed, then open a new issue or so.
@rugk @jerry Yeah, I don't agree with
@RandomDamage . Systemd is fundamentally doing a reasonable thing: trusting a subsystem whose job it is to authenticate users. That subsystem, sadly, fails open. I mean an ASSERTION is exactly the kind of failure that you should fail closed on. It's literally a failure of a foundational assumption. Systemd does not make a mistake by trusting polkit.
The standard is a bit higher for that sort of thing.
Besides, there are distributions that have moved away from OpenSSL over the security bugs there. It is a reasonable thing to do.
There's a difference between theory and practice. It's all well and good to spout a first principle like "it shouldn't trust polkit" but that lack of trust has to manifest in specific code behaviour. If we "don't trust" polkit, what do we do? Implement AuthN ourselves? That way leads to tears. And @rugk's analogy to OpenSSL is a good one. I hate systemd as much as any BSD guy might. But in THIS case they're being reasonable. @RandomDamage
Thuis is exactly the systemd critisim you always hear. But if they don't do this, people like @RandomDamage also criticizes it.
I indeed also don't know what he expects they should do.
What they did made sense with what they knew at the time, now they know different and their response is "not our code, not our problem".
What they *should* do is not accept the response of the auth system if it generates any response but an unqualified authorization, whether through stderr or response code, but that would involve dealing with someone else's interface so they'll probably just rewrite it if they ever care.
@RandomDamage @rugk I don't think you understand how these two processes are interacting. And saying "what they should do is NOT..." is not answering the question "what should they do?" People write code that DOES something. They don't write code that does NOT do something. And I don't think you're contemplating what the code must DO, in order to NOT do the things you think it shouldn't do.
A Mastodon instance for info/cyber security-minded people.