Don’t prohibit applications from including authorization rules

[polkit-github-migration-bot]

In gitlab.freedesktop.org by bugzilla-migration on Jul 4, 2014, 19:41

Link to the original issue: https://gitlab.freedesktop.org/polkit/polkit/-/issues/52

Submitted by Miloslav Trmac

Assigned to David Zeuthen @david

Link to original bug (#80921)

Description

Based on https://bugzilla.redhat.com/show_bug.cgi?id=956005:

The polkit manual states this:

"Authorization rules are intended for two specific audiences

System Administrators

Special-purpose Operating Systems / Environments

and those audiences only. In particular, applications, mechanisms and general-purpose operating systems must never include any authorization rules."

However, it’s become clear that the .action mechanism is not sufficient for expressing various real-world situations (look in /usr/share/polkit-1/rules.d/ ; e.g. gnome-initial-setup and lightdm needs extra access for their special-purpose users, or allowing access to “wheel” members without a password,).

Extending the .action mechanism, or inventing yet another one, purely to keep some abstract separation between users’ and programmers’ policy, is not reasonable; so just remove the documentation discouraging applications from adding their own .rules.

(I can’t see an any obvious middle ground between just prohibiting it, and just allowing it: in particular, allowing applications to only drop in .rules for their own actions isn’t sufficient, see gnome-initial-setup above for a counterexample.)

[polkit-github-migration-bot]

In gitlab.freedesktop.org by bugzilla-migration on Jul 4, 2014, 19:45

:hammer_and_wrench: Miloslav Trmac submitted a patch:

Patch 102279, "0001-Don-t-prohibit-applications-from-including-authoriza.patch":
0001-Don-t-prohibit-applications-from-including-authoriza.patch

[polkit-github-migration-bot]

In gitlab.freedesktop.org by bugzilla-migration on Jul 8, 2014, 23:12

:speech_balloon: David Zeuthen @david said:

I'm not sure removing this is a good idea and I think e.g. gnome-initial-setup is just busted or trying to do something wrong. I don't have a working Fedora system right in front of me - can you please post one of these files, for example the one from gnome-initial-setup? Thanks!

[polkit-github-migration-bot]

In gitlab.freedesktop.org by bugzilla-migration on Apr 1, 2015, 20:44

:speech_balloon: Michael Catanzaro said:

gnome-initial-setup ships this rule:

polkit.addRule(function(action, subject) { if (subject.user !== 'gnome-initial-setup') return undefined;

var actionMatches = (action.id === 'org.freedesktop.udisks2.filesystem-mount-system' ||
                     action.id.indexOf('org.freedesktop.hostname1.') === 0 ||
                     action.id.indexOf('org.freedesktop.locale1.') === 0 ||
                     action.id.indexOf('org.freedesktop.accounts.') === 0 ||
                     action.id.indexOf('org.freedesktop.timedate1.') === 0 ||
                     action.id.indexOf('org.freedesktop.realmd.') === 0 ||
                     action.id.indexOf('org.freedesktop.RealtimeKit1.') === 0);

if (actionMatches) {
    if (subject.local)
        return 'yes';
    else
        return 'auth_admin';
}

return undefined;

});

gnome-control-center uses this rule:

polkit.addRule(function(action, subject) { if ((action.id == "org.freedesktop.locale1.set-locale" || action.id == "org.freedesktop.locale1.set-keyboard" || action.id == "org.freedesktop.hostname1.set-static-hostname" || action.id == "org.freedesktop.hostname1.set-hostname" || action.id == "org.gnome.controlcenter.datetime.configure") && subject.local && subject.active && subject.isInGroup ("wheel")) { return polkit.Result.YES; } });

We're considering adding the following rule to ABRT:

polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.problems.getall" && subject.active == true && subject.local == true && subject.isInGroup("wheel")) { return polkit.Result.YES; } });

These last two are to express the rule "unprivileged users must authenticate but admin users need not authenticate." It would be nice to have less-cumbersome syntax for this, and a way to figure out if the subject is in the configured polkit admin group without assuming (often incorrectly) that it's wheel.

[polkit-github-migration-bot]

In gitlab.freedesktop.org by bugzilla-migration on Apr 23, 2016, 20:00

:speech_balloon: Miloslav Trmac said:

Colin, what do you think?

[polkit-github-migration-bot]

In gitlab.freedesktop.org by bugzilla-migration on Apr 23, 2016, 22:30

:speech_balloon: Michael Catanzaro said:

Some more. Note that most of these use "wheel" and will be broken on Debian/Ubuntu.

50-libvirt.rules:

// Allow any user in the 'libvirt' group to connect to system libvirtd // without entering a password.

polkit.addRule(function(action, subject) { if (action.id == "org.libvirt.unix.manage" && subject.isInGroup("libvirt")) { return polkit.Result.YES; } });

org.freedesktop.fwupd.rules:

polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.fwupd.update-internal" && subject.active == true && subject.local == true && subject.isInGroup("wheel")) { return polkit.Result.YES; } });

org.freedesktop.packagekit.rules:

polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.packagekit.package-install" && subject.active == true && subject.local == true && subject.isInGroup("wheel")) { return polkit.Result.YES; } });

[polkit-github-migration-bot]

In gitlab.freedesktop.org by bugzilla-migration on Apr 23, 2016, 22:39

:speech_balloon: Miloslav Trmac said:

Arguably most of the "wheel" rules should be a native functionality of polkit, if that security model is what we have settled on; though no idea if/when that would happen.

The initial-setup example is, to me, the governing example.

A reasonable philosophy is that permission models should be simple and automated, and the intelligence should be in applications; in such a case the various services should already know about initial-setup and use a different action for this caller (so which would be simply allowed in polkit), or perhaps user:initial-setup should be considered an authenticated administrator (and the default auth_admin would apply).

Another reasonable philosopy is that applications should be simple, and the permission model should be programmable; that leads to the gnome-initial-setup JS rule shipped in the package.

I am personally more in favor of the first one (complex applications, simple permission models), but the JS polkit is inherently implyting the second philosophy, so allowing applications to ship programmable rules seems to be an unavoidable consequence.

[polkit-github-migration-bot]

In gitlab.freedesktop.org by bugzilla-migration on Apr 23, 2016, 23:20

:speech_balloon: Michael Catanzaro said:

Most of these rules could be handled by some extension to the current pkla files. E.g. in addition to allowing yes, no, auth-admin, auth-admin-keep, there could be a simple "admin" rule that allows the action without password for admin users, and otherwise functions as auth-admin.

gnome-initial-setup is really the exception here, in that it depends on the username.