Draft privilege escalation policy for comments

[Kevin Kofler]

Adam Williamson wrote:
> I think it's sensible, yeah. It's not really much bureaucracy; I don't
> think it would ever be a good idea to introduce a new privilege
> escalation mechanism without FESco knowing about it...

Right now we're in a phase where a lot of stuff (system-config-*, several 
parts of KDE and some other stuff) is getting ported from running the whole 
app under consolehelper or kdesu to PolicyKit mechanisms. This is generally 
seen as a *good* thing. It'd be really annoying to have to go through a 
FESCo vote for every single one of those.

At the very least, I'd suggest adding the following clause to that 
paragraph:
"Any mechanism which requires administrative authentication to perform the 
privileged action (e.g. auth_admin policy in PolicyKit, kdesu etc.) is NOT a 
privilege escalation mechanism for the purposes of this paragraph."

Rationale: Such a policy does not impact the system's security as you have 
to enter the root password before doing anything dangerous, so none of the 
invariants under "Requirements" can be violated. And additionally, you can 
always as a user run the whole app under e.g. kdesu and thus "escalate your 
privileges" using the root password, so it doesn't make sense to police apps 
providing such a mechanism. What really matters for security is what you can 
do WITHOUT the root password. This is not really clear from the policy as 
written now, adding the suggested sentence would clarify it.

(That said, I don't see even the clarified policy as being necessary. We 
have a set of guidelines, maintainers should follow them, why do we have to 
police them? As I explained before, there is no evidence that this is 
necessary or useful. The PackageKit issue was caused by lack of a policy, 
not lack of enforcement.)

        Kevin Kofler