Control: reassign -1 src:policykit-1 Sorry, wrong source package name; forwarding this to make sure other maintainers see it.
On Thu, 01 Sep 2022 at 18:30:42 +0100, Simon McVittie wrote: > Source: polkitd > Version: 0.105-33 > Severity: important > Tags: patch > X-Debbugs-Cc: t...@security.debian.org, dukt...@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.
