policy+rule advice/features for granular allow-listing of pkexec actions based on more than just org.freedesktop.policykit.exec.argv1

[polkit-github-migration-bot]

In gitlab.freedesktop.org by jokeyrhyme on Jul 10, 2023, 09:20

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

Current behaviour, description of the problem

I'd like to authorize non-root users on my system to run /usr/bin/btrfs but only for a specific set of sub-commands with a specific set of flags

I can write a policy using the org.freedesktop.policykit.exec.argv1 annotation to allow-list e.g. /usr/bin/btrfs scrub (which might cause a DoS but doesn't leak data or privileges, so this is a risk level I am happy with on this particular system)

But most of the other sub-commands have sub-sub-commands that are potentially destructive or confidential, so allow-listing based on argv1 is insufficient e.g. I want to allow-list /usr/bin/btrfs balance status without also allow-listing /usr/bin/btrfs balance start

pkexec does expose a "command_line" variable that can be interrogated during rule evaluation, however, the manual page says:

The requested command-line (do not use this for any security checks, it is not secure).

Desired behaviour

It would be great for my use case if there was a secure/recommended way to write a combination of policy and rule that is securely-sensitive to arguments beyond argv1

Supporting policy matches based upon argv2 would cover all of my current use cases, but it's possible that someone would then encounter a case where they need argv3, etc so there's a bit of a slippery-slope to this approach

Some clarification in the documentation to explain why "command_line" is unsafe could be useful, and I wonder if this might be an old recommendation that no longer applies to modern polkit versions? Or perhaps there is a specific approach to working with this value in a rule that addresses potential risks?

Detailed description

polkit 122-1
Archlinux