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?
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/btrfsbut only for a specific set of sub-commands with a specific set of flagsI can write a policy using the
org.freedesktop.policykit.exec.argv1annotation 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
argv1is insufficient e.g. I want to allow-list/usr/bin/btrfs balance statuswithout also allow-listing/usr/bin/btrfs balance startpkexecdoes expose a"command_line"variable that can be interrogated during rule evaluation, however, the manual page says: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
argv1Supporting policy matches based upon
argv2would cover all of my current use cases, but it's possible that someone would then encounter a case where they needargv3, etc so there's a bit of a slippery-slope to this approachSome 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