Use of Javascript rules in polkit

polkit is a service used in Ubuntu that allows unprivileged processes to access system services. It is invoked when you do things like:

  • Change the system date/time.
  • Add/remove users from Settings.
  • Installing/removing software

When you do these a dialog often pops up for your password, though this is configurable by the system administrator.

In Debian and Ubuntu we are running polkit 105, which is almost 8 years old due to upstream switching the configuration backend from a PKLA (keyfile based) format to a more flexible JS format. This was done using the mozjs library which was not considered secure enough at the time to use in Ubuntu.

Example of a PKLA rule:

[Normal Staff Permissions]
Identity=unix-group:staff
Action=com.example.awesomeproduct.*
ResultAny=no
ResultInactive=no
ResultActive=yes

Example of a JS rule:

// Allow systemd-networkd to set timezone, get product UUID,
// and transient hostname
polkit.addRule(function(action, subject) {
    if ((action.id == "org.freedesktop.hostname1.set-hostname" ||
         action.id == "org.freedesktop.hostname1.get-product-uuid" ||
         action.id == "org.freedesktop.timedate1.set-timezone") &&
        subject.user == "systemd-network") {
        return polkit.Result.YES;
    }
});

Obviously the JS rules are a lot more flexible.

I’m currently investigating if we can update to the latest version of polkit (116 at this time) as it is desirable to get back into sync with upstream.

If you are using polkit rules on a system you are running can you comment here if:

  • You are running polkit on Ubuntu and have found the current PKLA format too limiting.
  • You are running other distros using newer versions of polkit with the JS support. Please give your experience of it.
6 Likes

@robert.ancell: that’s long overdue. Good luck in tackling that thing. And thanks!

5 Likes

Hey there,

I am using PKLA rules and find them too limiting. The most limiting factor is that there is no whitelisting functionality.

You can white or blacklist too narrow or broad groups, as I stated in my post. I don’t know how I missed this one …

I need modern polkit for https://gitlab.com/mikhailnov/system-autoupdate/-/blob/master/usr/share/polkit-1/rules.d/90-system-autoupdate.rules to work properly in Ubuntu. Writing rules in javascript and using a javascript engines to parse them sounds strange but is probably mostly ok in security terms, I can’t imagine an exploit.

In my case, I need the ability restrict users’ access to libvirt (only allow domains prefixed with $USER-), similar to: https://github.com/fxkr/virt-access/blob/master/23-virt-access.rules
The PKLA rules are too inflexible for libvirt.

I have been trying to work out why the polkit rules for udisks, udisks2 and udiskie were not working, on headless machines, but the reference to the “old” version in the documentation was working. Now I understand!

I would like to be able to filter by which unit is being managed and which management action, underneath the too-wide blanket of manage-units or manage-unit-files even if there is no JavaScript engine. It should be possible to add some more features to the pkla format to at least support this common use case.

It’s unlikely that new features will be added to the old pkla format unless upstream decided to re-adopt it.

I asked about some months ago too to debian maintainer about, and that’s where things are more complicated as there are less fans of JS rules there, so I think we should coordinate there to avoid having to maintain polkit alone.

1 Like

Agreed, and the historical issue was that it’s been considered up until now undesirable to have a Javascript engine in the mix here. I know that people have thought about using something smaller than Spidermonkey such as Duktape. That might be a solution which could work for us, but it’d have to be discussed with the security team first.

The good thing is that polkit is safe without JS.
Right? => CVE-2021-3560 => OK maybe not in the past => But now it is safe again without JS

What’s the reason Ubuntu 18.04/20.04 ships with /etc/polkit/rules.d and /usr/share/polkit/rules.d and lots of JS rules when it doesn’t support them? That’s just WTF.

Debian doesn’t do that. Additionally, polkit should be updated by Canonical as Debian stubboness is harming Ubuntu’s enterprise usage.

5 months ago, support for the smaller JS engine, Duktape, has been merged into polkit’s master branch:
https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/97

There has not been a release that includes this yet but there’s a pre-release of polkit 121 available.

I don’t know if the security team will be happy with Duktape but I’m guessing that has a better chance of being accepted so I’m hopeful :slight_smile:

The old PKLA format is also a cause of limitation for me, in being able to control access rights over remote connections for headless GUI enabled machines.

Please see this XRDP discussion for specifics: https://github.com/neutrinolabs/xrdp/discussions/2306

If users require working in JS, it doesn’t mean that JS language could be also running it. There are langs like Dart which could make using JS with dart:js interpreter but that is only one of possible choice for GNOME extension untrusted developers if something like this will be possible…

If GNOME uses mozjs for their extensions and such thing needs to be supported anyway in LTS, Debian choice for unproblematic PKLA or less powerful Ducktape.org in upstream polkitd support is only on a way for Choice of language and its on polkitd to have it by proper way implemented.

Don’t expect common extension developers to do something with PKLA, but also don’t expect GNOME extensions be stored somewhere under root files and not in home directory even in the case of Ubuntu shipping it on its installation…

If current language of choice was somehow chosen JS and Rust is not supported(and GNOME extensions has no such lang support yet), proven Debian way for polkitd with PKLA and insisting for it doesn’t mean that GNOME extensions had to do something with it. If there are additional applications, there is also AppArmor way of thinking(also complicated SELinux) and also powerful udev which makes this post a complete mess…

But if current language understanding and also its implementation is vague, but users something requires, they could :smiley: and if Debian or polkitd upstream is prepared, than according also by some development in this area and by enterprise or user politics and their Choice of apps and their ecosystem upstream will adapt.