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.
@rugk @jerry @paco while this isn't a systemd bug in particular, there is an architecture failure that allows this sort of bug to have such impact.
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.
Okay, so consider changing perspectives (fictional):
nginx is a security sensitive websystem.
Now that OpenSSL has a bug and fails open, it's a bug to keep relying on it.
Period.
– That's literally the same logic.
@rugk @paco @jerry systemd is the lowest level userspace process in the system, and they are taking on a lot of responsibility on top of that.
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.
@RandomDamage @paco @jerry we're totally getting off-topic…
So, let's agree to disagree…?
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
@RandomDamage @rugk It might be obvious to you, but it isn't obvious to me. What should systemd have done to protect against this error?
@paco @RandomDamage indeed if systemd implemented their own auth mechanism, people would cry "hey, it does not use polkit. Why? It always implements it's own stuff."
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.
@paco @rugk what should they do *now that they know it's a problem*?
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.
@rugk @paco @jerry assuming we're even disagreeing. Systems analysis is tricky.