[Debian-iot-maintainers] Bug#1018897: policykit-1: should use upstream version >= 121 in Debian 12

[Simon McVittie]

Source: polkitd
Version: 0.105-33
Severity: important
Tags: patch
X-Debbugs-Cc: team at security.debian.org, duktape at packages.debian.org

We have effectively been maintaining a fork of polkit 0.105 in unstable
since 2013, and it's unsustainable. The reason why we were stuck on
0.105 for so long is that maintainers didn't want to move from .pkla to
JavaScript as a format for authorization rules, for these reasons:

1. philosophical: .pkla is declarative, the JavaScript rules are
   imperative (and indeed Turing-complete)
2. practical: mozjs is not an easy project to have as a dependency
3. practical: the migration path from .pkla to JavaScript for sysadmins'
   local configuration is not obvious

I believe we now have consensus among the maintainers that (1.) is not a
blocker for updating to a new upstream release.

(2.) has been solved in experimental by upstream support for using duktape
instead of mozjs. If mozjs is like nodejs or Python, then duktape is
more like Lua: it's a smaller and more limited JavaScript implementation,
optimized for small size rather than features and speed.

Now that the use of JavaScript is not a barrier, (3.) has been solved
in experimental by converting the polkitd-pkla package into an optional
addon, which hooks into the JavaScript implementation of polkitd and calls
out to a helper executable which implements the old .pkla configuration
format. I have also reported bugs tagged in
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-utopia-maintainers%40lists.alioth.debian.org&tag=pkla-without-js
for all the packages that include .pkla configuration with no JavaScript
equivalent, which will not work as intended when users install
polkitd-javascript but do not install the suggested package polkitd-pkla.

I think this means the pieces are all in place for merging the
version from experimental into testing/unstable, and we have consensus
among the package's maintainers that we want the polkitd-javascript
implementation to be the only one, with polkitd-pkla as an optional
addon for backwards-compat (this would put us in the same situation
as Fedora and RHEL). I've cc'd the security team and the duktape
maintainers in case they are aware of any showstoppers with this plan.

Previous discussion is in
https://salsa.debian.org/utopia-team/polkit/-/merge_requests/6 and
https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/1972654.

Security implications
---------------------

Not using a 9 year old fork of polkit would make the maintainers a lot
more comfortable about not having implementation errors in the C code.
I have tried to backport fixes from upstream polkit, but 9 years is a long
time to be doing that across and not all patches can be applied.

The JavaScript that is interpreted to carry out policy checks is totally
trusted (the whole point of it is that it lets the sysadmin choose who can
do what with elevated privileges), so it is not a problem if duktape can be
made to do bad things by using attacker-controlled JavaScript: if there is
attacker-controlled JavaScript in use, we have already lost.

The JavaScript rules can interact with objects provided by polkit, which
can have metadata provided by the service that is querying the policy.
This metadata might be attacker-controlled in some cases, so duktape's
string processing is potentially security-senstive here.

If users upgrade polkitd without installing the optional package
polkitd-pkla, then any local .pkla customization will not run, which
might mean that restrictive non-default policies get reset to being
less restrictive.

Remaining things to do
----------------------

Security team and duktape maintainers: do you have any strong objections?

We need to decide: do we ship polkitd-pkla in Debian 12, or remove
it? There was no consensus among maintainers on this: Martin Pitt and
Iain Lane thought we should ship it, Michael Biebl thought we should not.

We need to decide: if we ship it, how strongly does polkitd depend on
it? A hard Depends is too strong, and would be circular. Recommends might
be justifiable, and would pull it in during 11 -> 12 upgrades, at the cost
of keeping this legacy code around (polkit-pkla-compat has essentially not
been touched since 2013 either). For the moment I've gone with Suggests.
I think we should definitely relax it to Suggests, or no dependency at all,
in the Debian 13 cycle.

Another thing we could do, if we want to, would be to give polkitd a
weak dependency on polkitd-pkla (Suggests or nothing at all), but give
the transitional package policykit-1 a stronger dependency (perhaps
Recommends) so that polkitd-pkla gets pulled in during upgrades from
Debian 11.

We should have a NEWS entry, but that's blocked by deciding what shape
the final packaging is going to be.

We should probably merge the polkitd and polkitd-javascript packages
back together at some point, but for now I've kept them separate, so
that if someone vetoes the use of JavaScript we won't have to go back
through NEW to redo the package split.

    smcv