Proposed F19 Feature: Usermode Migration

[Kevin Kofler]

Jaroslav Reznik wrote:
> = Features/UsermodeMigration =
> https://fedoraproject.org/wiki/Features/UsermodeMigration
> 
> Feature owner(s): Harald Hoyer <harald at redhat.com>, Kay Sievers
> <kay at redhat.com>, Bill Nottingham <notting at redhat.com>
> 
> Access control of privileged operations for ordinary users should be
> handled exclusively by a centrally managed authority.
> 
> Usermode/consolehelper should be phased out and be replaced entirely by
> polkit.

So this feature advertises:

> These days, most privileged system operations are already controlled by
> polkit, a well-established, fine-grained, (possibly) network-transparent
> service for managing privileged operations by ordinary users. Enterprise
> environments need to be able to centrally define access control policy for
> the organization, and automatically apply it to all connected
> workstations.

which is indeed how PolicyKit is intended to be used. See here the word 
"fine-grained". Then when you go at how the migration is actually supposed 
to be implemented, you see:

> For directly executed tools, polkit provides a setuid-root helper program
> called ‘’pkexec’’.
and in the details:
> python: put a pkexec invocation in the wrapping shell script 
> C tools: re-exec with pkexec in C code 
> C tools: move original to /usr/lib/<pkg>/<tool>, and wrap /usr/bin/<tool>
> with a pkexec shell script (ugly!)

This is falling WAY short of the advertising! pkexec entirely defeats the 
purpose of using PolicyKit! Instead of having a specific permission, such as 
org.kde.kcontrol.kcmclock.save, which admins can give to their users in good 
conscience (even if they do NOT trust them to do anything OTHER than the 
fine-grained allowance the permission represents), you have a 
org.freedesktop.policykit.exec permission which is trivially equivalent to 
root access (because it allows you to execute arbitrary code as any user 
including root). Therefore, you degrade PolicyKit into a device to prompt 
for the root password (or a wheel user password, the sudo way). It is 
impossible to give out fine-grained permissions this way. I don't see what 
"access control policy" other than auth_admin you'd define for 
org.freedesktop.policykit.exec in an "enterprise environment"; surely you 
aren't planning to give your users root access!

I don't see why this misfeature was accepted for F18. It is entirely useless 
under this form. We need a feature to actually use PolicyKit the way it was 
intended, phasing out usermode, consolehelper, kdesu and pkexec all at once 
wherever it is possible. (Of course, if the feature to be implemented really 
is "let the user run app 'foo' as root", then using pkexec or kdesu is a 
suitable solution.) Of course, this is much more work and often requires 
upstream cooperation (and probably a security audit! I've seen some "fine-
grained" mechanisms which are no more secure (for non-auth_admin) in 
practice than org.freedesktop.policykit.exec). But using pkexec is just a 
quick hack to swipe the issue under the carpet and does not solve the real 
problem at all!

        Kevin Kofler