This was asked on the mailing list, but never answered I think:
if polkit has pkla rules it doesn't understand (because polkit-pkla-compat is not installed), what happens? Are actions denied by default?

I believe it was answered: they are allowed.

Note that the proposal as it is written right now will not remove those packages from the default installation of most Fedora editions as we install recommended packages by default.

Most desktops also currently indirectly depend on pkexec and we will end up adding 'Require: pkexec' to those packages.

For pkla compat rules, my understanding is that polkit will simply not read them without the compat module thus they won't be applied. This means:
- Additional rules granting access will be ignored thus the access will be denied.
- Additional rules denying access will be ignored thus the access will be granted. This only applies to access that would have been granted from the default rules. This is indeed the most problematic issue here. (https://www.mankier.com/8/pkla-check-authorization)

@jrybar should be able to confirm my understanding.

@mitr is the author of pkla-compat, I believe he has way more profound answers to this.

ad pkexec) separating the binaries poses an unnecessary risk and effort to other packages with little gain, especially if this whole topic was brought up by hysteria around CVE-2021-4034, which was patched fast, buttersmoothly and by the numbers in terms of embargo security procedures. Thanks to the Product Security team, QA and reporter for their great work!

(Note that I’m not working on this software at all, any more, so I might have opinions but I would not bear most of the impact.)

I don’t feel strongly about separating pkexec; it might remove some risk, OTOH as Lennart argues, Fedora should have some recommendation for how to escalate privileges — I think that has been “Use a polkit-mediated D-Bus server, or in the worst case, pkexec”; but I’m out of the loop. And it would still be possible to have that recommendation, and just require a RPM dependency on pkexec in its users.

WRT polkit-pkla-compat, https://src.fedoraproject.org/rpms/polkit/pull-request/2#comment-79472 . :

• The cost and risk of polkit-pkla-compat being installed is very small.
• I think the JavaScript configuration mechanism built into polkit (one that is, admittedly, very powerful) is overall a bad choice, and polkit-pkla-compat (using the same mechanism that is, IIRC, still used in Debian) is, IMHO, the best alternative we have right now. So removing that from the default install, implicitly recommending the JavaScript mechanism, is not that attractive a proposition to me (but again, this is not up to me).

Overall I think leaving polkit-pkla-compat installed in the default configuration is well worth it.

WRT the technical aspects of polkit-pkla-compat:

• I would be 100% opposed to removing polkit-pkla-compat on upgrades; silently opening up restrictive security configuration is just not worth it IMO.
• Not installing polkit-pkla-compat on fresh installations is more reasonable. Any packages that currently ship PKLA configuration would need to add a dependency, at the very least.
• I don’t know what to do about any existing user automation, or guides/documentation, setting up PKLA files. Polkit itself is unaware of PKLA, so it doesn’t warn in any way that PKLA files are ignored. I could see an argument for patching Polkit itself to warn, and I could see an argument that users with configuration automation should read release notes and test their configuration — both are rather unattractive to me.

With all this in mind, I'm -1 to this proposal. It's too dangerous and risky.

How will the package sizes look after the split? pkexec is small.

(Also: isn't there some overlinking in the two binaries: both pkexec and polkitd have the same link list, I'd expect pkexec to be smaller.)

Oh, I see it in copr:

polkit-0.120-4.fc36.x86_64.rpm  2022-Feb-16 10:28:20    135.89K     RPM File
polkit-devel-0.120-4.fc36.x86_64.rpm    2022-Feb-16 10:28:24    40.38K  RPM File
polkit-docs-0.120-4.fc36.noarch.rpm 2022-Feb-16 10:28:17    241.82K     RPM File
polkit-libs-0.120-4.fc36.x86_64.rpm 2022-Feb-16 10:28:23    65.76K  RPM File
polkit-pkexec-0.120-4.fc36.x86_64.rpm   2022-Feb-16 10:28:22    22.74K  RPM File

So size-wise, the difference is tiny. But maybe if linking is reduced, we could still have an advantage in reduced deps.

From the meeting:

Eighth_Doctor> zbyszek: Polkit fails open by default, not closed, you need a rule to block by default first
Eighth_Doctor> nobody has that

Hmm, @ngompa do you have any reference to this? The docs don't say anything one way or another, but that'd seem very very risky.

From @mitr earlier in this ticket:

I would be 100% opposed to removing polkit-pkla-compat on upgrades; silently opening up restrictive security configuration is just not worth it IMO.

In that, I was not referring to defaults, just to configuration files. (polkit’s default decisions are set up in /usr/share/polkit-1/actions ).

Any of the .pkla files can have an entry saying (identity=… ; action=…; result… = no). (e.g. “deny $action to members of a UNIX group”, or possibly “deny $action by default”). If polkit-pkla-compat is not installed, these .pkla files will be silently ignored, and $action will be allowed, while the user intended it to be denied.

… or rather if the PKLA file is ignored, the decision on $action will be decided by other rules, e.g. other JavaScript rules, or the default in /usr/share/polkit-1/actions .

… or rather if the PKLA file is ignored, the decision on $action will be decided by other rules, e.g. other JavaScript rules, or the default in /usr/share/polkit-1/actions .

Yes. That is a scenario that we also discussed during the meeting yesterday. But I think it's contrived / unlikely-to-realistically-matter, because you'd need three conditions to coincide: some permissive config in js, a restrictive config in pkla that restricts that first one, and the admin removing polkit-pkla-compat. This is certainly possible, but since the proposal would keep polkit-pkla-compat on upgrades, and we don't install any pkla config by default, this would be in the territory of explicitly conflicting admin actions.

--

Polkit fails open by default, not closed, you need a rule to block by default first
nobody has that

@ngompa I understand that by this you were referring to the scenario that @mitr described. Since you said "you need a rule to block by default, nobody has that", it sounded like you were saying that polkit allows actions by default.

This was discussed during today's meeting:
info: we're waiting for more input from Change Owners.

There has still been no further response on the list, so far as I can tell.

splitting pkexec) I'm against this change.
- over 90 dependencies on polkit -> grep each and search for calling pkexec -> change their .spec files = too long, risky and ...
- too much effort to save 20kb?!
- this whole thing started with the public freaking out because of CVE-2021-4034. Yes, it was a scary one, but was fixed effectively, all other binaries checked for the same (or similar) issue and no software is spared a CVE from time to time. Useless hysteria in this case, I see no benefit here, only risks, sweat and tears.

splitting pkla-compat) I'm not against this change. pkla-compat is a legacy software added for compatibility with local authority in 2013 and I don't see any component directly dependent on pkla-compat. AFAIK all rules now use JS engine in polkit. The change in .spec file should be trivial.

The Change Owner has responded to comments. Can we begin the voting period again or are there additional concerns FESCo wants addressed first?

The benefits are indeed rather weak, and with the lackluster support from change owners, I think it's better to drop this.

-1

-1 still.

https://meetbot.fedoraproject.org/fedora-meeting/2022-04-05/fesco.2022-04-05-17.00.html

REJECTED (+0, 3, -5)