should recognize configuration files in /usr/local/share/polkit-1

[polkit-github-migration-bot]

In gitlab.freedesktop.org by bugzilla-migration on Jan 12, 2017, 03:20

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

Submitted by beommasha

Assigned to David Zeuthen @david

Link to original bug (#99374)

Description

on my system, policykit is grabbing configuration files from: /usr/share/polkit-1 it should also grab configuration files from: /usr/local/share/polkit-1

what's the difference? the subdirectories of /usr/local contain material specific to a particular host -- they're for use by an administrator to keep their own custom files from being overwritten by packages that get installed or updated.

for example, as things stand currently with policykit, the administrator has to put e.g. yumex.rules in /usr/share/polkit-1/rules.d -- but if an update to the yumex application starts including it's own yumex.rules, it will overwrite the administrator's configurations and they will be lost :-/

on the other hand, if policykit recognizes /usr/local/share/polkit-1, the smart administrator can place their yumex.rules within /usr/local/share/polkit-1/rules.d and not have to worry about it being overwritten.

[polkit-github-migration-bot]

In gitlab.freedesktop.org by bugzilla-migration on Oct 9, 2017, 10:15

:speech_balloon: Mirko Brombin said:

It may be useful to run a setup.py to add a policy, as normally on a system, python packages are installed in/usr/local.

[polkit-github-migration-bot]

In gitlab.freedesktop.org by bugzilla-migration on Oct 9, 2017, 13:12

:speech_balloon: Miloslav Trmac said:

on the other hand, if policykit recognizes /usr/local/share/polkit-1, the smart administrator can place their yumex.rules within /usr/local/share/polkit-1/rules.d and not have to worry about it being overwritten.

That’s not how the *.rules file loading works; all of the files are loaded, in a lexical order, even if they have the same base name.

Instead, you can name the override e.g. 00-yumex.rules, and the code run in there will be run before whatever the yumex package installs in yumex.rules.

As for /usr/local being specific to a particular host, why not just use /etc?

[polkit-github-migration-bot]

In gitlab.freedesktop.org by bugzilla-migration on Oct 9, 2017, 15:17

:speech_balloon: beommasha said:

As for /usr/local being specific to a particular host, why not just use /etc? I assume you're making reference to /etc/polkit-1/rules.d ... but what about the absent /etc/polkit-1/actions? adding that directory and placing a .policy file in there has no effect. also, is it documented somewhere that packages cannot / should not place policykit .rules or .policy files in /etc?

Instead, you can name the override e.g. 00-yumex.rules, and the code run in there will be run before whatever the yumex package installs in yumex.rules. is it documented somewhere that packages cannot / should not name policykit .rules or .policy files starting with "00-"?

keep in mind i wasn't referring to configuration being merely overridden, but overWRITTEN (as in the custom configuration files' contents lost).

[polkit-github-migration-bot]

In gitlab.freedesktop.org by bugzilla-migration on Oct 9, 2017, 15:34

:speech_balloon: Miloslav Trmac said:

(In reply to beommasha from comment 3) As for /usr/local being specific to a particular host, why not just use /etc? I assume you're making reference to /etc/polkit-1/rules.d ... but what about the absent /etc/polkit-1/actions? adding that directory and placing a .policy file in there has no effect.

That runs into exactly the same issue; actions/* are not designed to be overridable by simply using the same file name. Override-by-file-name is a systemd-ism not at all common in the ecosystem.

Besides, actions/ are application-installed static files not anticipated to be overridden and not designed to be overridable. Whatever the administrator is expected to want to change should be doable using .rules files. (Or, if we are talking about changing/adding translations and core properties, that’s really changing the application, not its configuration, and it seems entirely appropriate to ask the administrator to package the changed application as an updated RPM.)

also, is it documented somewhere that packages cannot / should not place policykit .rules or .policy files in /etc?

Instead, you can name the override e.g. 00-yumex.rules, and the code run in there will be run before whatever the yumex package installs in yumex.rules. is it documented somewhere that packages cannot / should not name policykit .rules or .policy files starting with "00-"?

Neither of these need to be documented; the system administrator, who is overriding the default .rules of a specific application, by definition knows what the original name of the application-installed .rules file is, and can therefore choose a file name which sorts before it.

It’s not interesting to speculate about what would happen if a future version of that package were updated to intentionally override the administrators’ configuration by choosing a different file name which sorts even earlier; the package is already running code as root, it can do whatever it wants without doing it in this difficult and limiting way.

keep in mind i wasn't referring to configuration being merely overridden, but overWRITTEN (as in the custom configuration files' contents lost).

That’s really up to the distributions packaging system. At least RPM would just overwrite a non-%conf file (such as /usr/share//.rules, yes) without warning, IMHO reasonably. Files marked as configuration are treated differently, usually with more care.

The admin can always embed the company’s name to make the file name unique. But between using /etc instead of /usr/share, and testing the changes, that is only a layer of insurance for extra confidence, not inherently necessary.

[polkit-github-migration-bot]

In gitlab.freedesktop.org by bugzilla-migration on Oct 9, 2017, 15:39

:speech_balloon: Miloslav Trmac said:

To step back a bit: It seems valuable to have all of the configuration consolidated in a single place, so that it is easy to understand it in its entirety. The /etc vs. /usr/share split is already more complex than this, to supposedly make shipping “stateless” systems much easier (not sure about that, honestly), and to cleanly separate distribution-shipped and administrator-created configuration (clearly true).

Adding /usr/local/share would make the configuration even more dispersed, making it easier for an administrator to overlook a configuration file (or, potentially, for an attacker to hide an unexpected override). And if it is not clear how /etc would differ from /usr/local/share, why have both?

[polkit-github-migration-bot]

In gitlab.freedesktop.org by bugzilla-migration on Oct 11, 2017, 01:10

:speech_balloon: beommasha said:

That runs into exactly the same issue; actions/* are not designed to be overridable by simply using the same file name.

I have not used the word override. The issue I'm describing is that the administrator's .policy files if placed into a package-writable place can be overwritten due to any naming conflicts that might eventually crop up. Not only would the intended functionality stop working at that point, but the administrator's work would also be lost. An example in which I use .policy files is to enable pkexec to work with certain applications. The following command, for example, will not work unless a custom .policy file is added: pkexec caja /;

If the administrator names the file pkexec.policy or caja.policy, or really anything else, there's potential that the file could get overwritten by a package update or installation. That's the issue I have been describing.

Whatever the administrator is expected to want to change should be doable using *.rules files

Can you tell me a way to make the command listed above work with a .rules file?

Neither of these need to be documented; the system administrator, who is overriding the default .rules of a specific application, by definition knows what the original name of the application-installed .rules file is, and can therefore choose a file name which sorts before it.

That's not the use case I've been describing. Please re-read original comment:

for example, as things stand currently with policykit, the administrator has to put e.g. yumex.rules in /usr/share/polkit-1/rules.d -- but if an update to the yumex application starts including it's own yumex.rules, it will overwrite the administrator's configurations

Therefore, the administrator doesn't strictly know what the file will be named. Maybe if/when yumex started including rules they'd name it 00-yumex.rules because they simply saw a .rules file labeled that way in an online example. The administrator has no guarantee their file won't be overwritten when an application is updated or installed.

It’s not interesting to speculate about what would happen if a future version of that package were updated to intentionally override the administrators’ configuration by choosing a different file name which sorts even earlier; the package is already running code as root, it can do whatever it wants without doing it in this difficult and limiting way.

mmmm ... snarky :-) um, again, and I can't seem to stress this enough ... these scenarios you're noting are your own inventions and have nothing to do with the use case I've been conveying.

That’s really up to the distributions packaging system. At least RPM would just overwrite a non-%conf file (such as /usr/share//.rules, yes) without warning, IMHO reasonably.

so it's your (apparently very strongly held) opinion that administrators should not be able to make customizations by making use of polkit .rules and .policy files?

It seems valuable to have all of the configuration consolidated in a single place ... Adding /usr/local/share would make the configuration even more dispersed, making it easier for an administrator to overlook a configuration file

the administrator who (properly) uses /usr/local/share for their custom stuff over /usr/share is not going to forget the difference

(or, potentially, for an attacker to hide an unexpected override).

straw grasping, much?

And if it is not clear how /etc would differ from /usr/local/share, why have both?

files placed in /usr/local (not just /usr/local/share) are protected by that distinction from being overwritten by package updates and installations. that's the difference.

[polkit-github-migration-bot]

In gitlab.freedesktop.org by bugzilla-migration on Oct 21, 2017, 19:10

:speech_balloon: Miloslav Trmac said:

(In reply to beommasha from comment 6) If the administrator names the file pkexec.policy or caja.policy, or really anything else, there's potential that the file could get overwritten by a package update or installation. That's the issue I have been describing.

OK…

It’s not interesting to speculate about what would happen if a future version of that package were updated to intentionally override the administrators’ configuration by choosing a different file name which sorts even earlier; the package is already running code as root, it can do whatever it wants without doing it in this difficult and limiting way.

mmmm ... snarky :-)

That’s not snarky; that is fundamental. In the Linux security model, administrators can’t be fighting with (non-sandboxed) applications they install; they are always going to lose.

If the administrator names a file mycompany-caja.policy, an ordinary application not out to attack the administrator is not going to conflict with that name. If the application is trying to attack the administrator and introduces a file named mycompany-caja.policy, then introducing /usr/share/local is not going to help at all because the application can just as well introduce an /usr/share/local/polkit-1/mycompany-caja.policy.

That’s really up to the distributions packaging system. At least RPM would just overwrite a non-%conf file (such as /usr/share//.rules, yes) without warning, IMHO reasonably.

so it's your (apparently very strongly held) opinion that administrators should not be able to make customizations by making use of polkit .rules and .policy files?

There’s the /etc space for .rules. You’re right that there isn’t a great place for introducing extra pkexec permissions for .policy, but there is a good enough place.

It seems valuable to have all of the configuration consolidated in a single place ... Adding /usr/local/share would make the configuration even more dispersed, making it easier for an administrator to overlook a configuration file

the administrator who (properly) uses /usr/local/share for their custom stuff over /usr/share is not going to forget the difference

Maybe; but only very few are regularly updating custom stuff in there, many more are going to be surprised the first time they see a config file in there.

And if it is not clear how /etc would differ from /usr/local/share, why have both?

files placed in /usr/local (not just /usr/local/share) are protected by that distinction from being overwritten by package updates and installations. that's the difference.

I don’t know about all possible package update systems, but this is certainly not the case for RPM at all, and it’s not really the case for any packaging system which allows packages to contain arbitrary scripts run as root. (And if you think that nobody would place files into /usr/* in a post-install script, this does happen, usually when a multi-platform vendor finds it necessary to make a package, any package that works well enough.)

[polkit-github-migration-bot]

In gitlab.freedesktop.org by pwithnall on Nov 22, 2018, 20:26

mentioned in commit pwithnall/polkit@e8ea1539a7636d7b6f34b66f57224b68ac3c30fe

[polkit-github-migration-bot]

In gitlab.freedesktop.org by pwithnall on Nov 27, 2018, 12:17

mentioned in commit pwithnall/polkit@03f5a750919243916f650e558a865d020ab42f6f

[polkit-github-migration-bot]

In gitlab.freedesktop.org by pwithnall on Nov 27, 2018, 12:17

mentioned in commit pwithnall/polkit@3f8728f2145c641d62cd87b8d2829a91a6faf67b

[polkit-github-migration-bot]

In gitlab.freedesktop.org by pwithnall on Dec 5, 2018, 17:41

mentioned in commit pwithnall/polkit@0a6e9ec8bc501b49bbe84094c6bb2c5e4d90861c

[polkit-github-migration-bot]

In gitlab.freedesktop.org by pwithnall on Dec 5, 2018, 17:41

mentioned in commit pwithnall/polkit@dd5722c20b235ff159a90b4e27c8869c35ad453b

[polkit-github-migration-bot]

In gitlab.freedesktop.org by pwithnall on Feb 25, 2021, 19:23

mentioned in commit jrybar/polkit@18d2cf4ee14cadd9b0ae8cc45bd6ad359e4e39b0

[polkit-github-migration-bot]

In gitlab.freedesktop.org by pwithnall on Feb 25, 2021, 19:23

mentioned in commit jrybar/polkit@c0dcd46d00ca0e7b3403628a9165418f935e91db

[polkit-github-migration-bot]

In gitlab.freedesktop.org by wmealing on Mar 2, 2023, 01:13

(or, potentially, for an attacker to hide an unexpected override). straw grasping, much?

I just had to comment, hindsight being 20/20.

I am auditing an exploited system, that used polkit configuration as a backdoor after they had already gained privesc via another method. The RPM checksum verification showed that these files were modified, if there was a secondary /usr/local which was not managed by RPM, this would have been much harder to track down.

Also, if it is config, why are these all not in /etc/. Can /usr/share/polkit-1/ be no longer used for configuration ?

I got no skin in the game, sorry if this i stirring up old wounds.

[polkit-github-migration-bot]

In gitlab.freedesktop.org by pwithnall on Mar 2, 2023, 01:38

This sounds like something which would be more appropriate for the mailing list rather than a gitlab issue which was resolved 4 years ago. :)

[polkit-github-migration-bot]

In gitlab.freedesktop.org by wmealing on Mar 2, 2023, 02:41

Yeah, probably. I can't afford to join another mailing list because I already get too much mail.

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jrybar on Mar 2, 2023, 17:04

Hello,

there is a strong initiative that all files and configuration provided by software vendor (i.e. package) shall reside in /usr subfilesystem and all custom-made, system-specific configuration should be in /etc.
Not only this aligns with Filesystem Hierarchy Standard, but also conforms the etc-less system enablement, which means that if an admin deletes/purges the /etc directory, that will reset the system to "factory settings".
Storing vendored configuration in /etc is not recommended. Default configs stored in /usr/... shall be shadowed by system-specific configs in /etc.

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s07.html
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html

[polkit-github-migration-bot]

In gitlab.freedesktop.org by wmealing on Mar 3, 2023, 06:48

Storing vendored configuration in /etc is not recommended. Default configs stored in /usr/... shall be shadowed by system-specific configs in /etc.

^ If thats written somewhere in the FHS, that's good enough for me, was there a third link which mentions (or implies) this ?

[polkit-github-migration-bot]

In gitlab.freedesktop.org by wmealing on Mar 3, 2023, 06:56

Just to be clear, this is not that big of a deal for me. Just trying to build some concepts around expectations.

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jrybar on Mar 3, 2023, 18:22

Sure :)
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s02.html // this for /etc as host-specific configuration
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html // this for program-installed non-modifiable (read-only) data stored in /usr/share
E.g. systemd-sysctl ($ man sysctl.d) uses this hierarchy precedencem, as well as many other software projects.