|
|
Subscribe / Log in / New account

Fedora and pkexec

Fedora and pkexec

Posted Feb 3, 2022 10:20 UTC (Thu) by cortana (subscriber, #24596)
Parent article: Fedora and pkexec

because the policy is free-form javascript rather than assignments that can be checked by any configuration scanners

On Debian (and derived distributions I guess) an older version of Polkit is shipped, which still uses the old 'pklocalauthority' where policy is written in static INI-like format, but you're limited to matching on properties like "is the requester a given user", "is the requester in a group*", "is the requster on an active console session", etc.

I go back and forward on whether this is good or not. The fragmentation between the Red Hat and Debian worlds here is aggravating. But the static policy is easier to understand!

* which it does in a broken way (upstream bug) that doesn't work in large installations, precisely the sort of installations that would like to use Polkit to control policy, argh!


to post comments

Fedora and pkexec

Posted Feb 3, 2022 23:07 UTC (Thu) by mchapman (subscriber, #66589) [Link] (3 responses)

Newer polkit still supports "polkit local authority" INI files through pkla-admin-identities + pkla-check-authorization. These can be invoked from the newer JavaScript-based authority, and the default polkit configuration does just that.

I'm wondering if Debian doesn't use a newer polkit simply because they object to using JS (or perhaps the old mozjs library?) in a security-sensitive context.

Fedora and pkexec

Posted Feb 4, 2022 17:59 UTC (Fri) by cortana (subscriber, #24596) [Link] (2 responses)

That proposed reasoning seems odd to me, mozjs is already exposed, via its use in Firefox, to the most hostile of all possible environments: the internet!

I wish the reason was documented in the package's README.Debian file...

Fedora and pkexec

Posted Feb 5, 2022 22:00 UTC (Sat) by khim (subscriber, #9252) [Link] (1 responses)

Firefox, like Chrome, doesn't trust it's renderers and sandboxes mozjs for a reason.

Polkit does the exact opposite.

Fedora and pkexec

Posted Feb 6, 2022 4:42 UTC (Sun) by mjg59 (subscriber, #23239) [Link]

The reason being that they're exposed to untrusted input in a way that polkit isn't?

Fedora and pkexec

Posted Feb 4, 2022 7:01 UTC (Fri) by zdzichu (subscriber, #17118) [Link] (5 responses)

Looking at my polkit rules, I have stuff like “allow smart home system (running as unprivileged user) to start specific services” which translates to something like:
polkit.addRule(function(action, subject) {
        if (action.id == "org.freedesktop.systemd1.manage-units") {
                var unit = action.lookup("unit");
                if (unit == "toggle-bcache@writethrough.service" ||
                    unit == "toggle-bcache@writearound.service" ||
                    unit == "toggle-bcache@writeback.service") {

                        var verb = action.lookup("verb");
                        if (verb == "start" && subject.user == "openhab" ) {
                                return polkit.Result.YES;
                        }
                }
        }
});
How to express that in previous INI-language? I doubt it's possible.

Fedora and pkexec

Posted Feb 4, 2022 10:19 UTC (Fri) by smcv (subscriber, #53363) [Link]

You are correct, it's not possible. Putting domain-specific extra information on an authorization request, and then using it as input to the authorization rules, is one of the major things that the JavaScript implementation can do and the old "local authority" (.ini-style .pkla files) did not have a representation for.

For example, when the privileged service asking for authorization is systemd, the domain-specific extra information can include a systemd unit name, as used in your example rules.

Fedora and pkexec

Posted Feb 4, 2022 11:00 UTC (Fri) by gioele (subscriber, #61675) [Link] (1 responses)

Even though expressing this kind of complex constraints with a INI-style configuration file is not feasible, in such a security-relevant piece of software it would had been more sensible to adopt and embed a small non Turing-complete language (for example CEL, available for C++ and Rust) instead of Javascript.

Fedora and pkexec

Posted Feb 15, 2022 15:51 UTC (Tue) by sammythesnake (guest, #17693) [Link]

CEL as in https://github.com/google/cel-spec ?

It took me a while to find the (hopefully) right "CEL" - it doesn't appear to be on acronym finder or Wikipedia which usually find these things for me, so I thought out might be useful for others similarly out of the loop :-P

Fedora and pkexec

Posted Feb 4, 2022 22:09 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (1 responses)

Just as a style nit: You may want to use === instead of == when writing Javascript. === does what you (probably) want, == tries to do implicit type coercion (poorly).

Reference: https://developer.mozilla.org/en-US/docs/Web/JavaScript/E...

Fedora and pkexec

Posted Feb 19, 2022 12:13 UTC (Sat) by cortana (subscriber, #24596) [Link]

Perfect example of why maaaaybe JavaScript was not the best choice of language for extending PolKit. :)


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds