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"


@jerry @paco mind to read the bug report? I know systemd bashing is popular and always funny, but this is polkit; so please bash it too! 😜

@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.

@paco @rugk @jerry systemd is a security sensitive subsystem. Now that it is *known* that polkit fails open, it's a bug to keep relying on it.


@RandomDamage @paco @jerry

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.


– 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…?

@rugk @paco @jerry assuming we're even disagreeing. Systems analysis is tricky.


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

@paco @rugk given the history of systemd casually replacing subsystems, I disagree with your assessment.

The priority is clearly "whatever is easiest for the developers of systemd", which is only reasonable if you are one of those developers.

@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.

@rugk @paco indeed, people would criticize them for doing so, but the choice on this issue reinforces the pattern of "if it's easier to reimplement it than to learn how to interface with someone else's program we'll rewrite it, otherwise we don't care even if it's a problem".

@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.

@paco @rugk what they should do is so far away from anything where the current situation is a problem that I simply cannot oblige your request.

Frankly, what they should do is *less* of everything, and they should do it as correctly as possible.

Sign in to participate in the conversation
Infosec Exchange

A Mastodon instance for info/cyber security-minded people.