Local Authority plan

[David Zeuthen]

Hey,

The last item for polkit for 1.0 is to provide a way to control
authorizations on a per-user and per-group basis when using the Local
Authority (called LA in the following).

First, what does this mean? It means being able to grant authorizations
to for an Action A and Identity I (such as a user U or a group G) such
that if a Subject S (e.g. a process running on your system with pid P or
D-Bus unique system bus name D) is owned by I and a Mechanism M is
asking whether S is authorized for A, then we know what to answer by
looking up files on the local filesystem (rather than defaulting to the
defaults in the .policy file like we do know).

(yes, that was terse, hopefully it will get easier to understand later
in this mail)

Second, let us look at the requirements for such a solution.

 o  OS vendors ship many different kind of products, we need it to be
    very easy to configure the LA; examples

    - need to configure all current and future actions to request admin
      authentication when needed (this makes sense on a "hardened"
      and "secure" system) - this probably means we need to use some
      kind of globbing or regexp

    - need a way for the OS vendor to ship the policy in files
      that are installed via RPMs (or similar) with relying on fragile
      %post snippets (or similar) being run on the target machine. In
      particular, can't rely on having the polkitd-1 daemon around at
      %post time (might run in a chroot for livecd creation etc.)

    - need a way to the organization owning the machine (e.g. a company
      deploying PolicyKit to ship policy files; these files override
      what the OS vendor provides. Again, installed via RPMs (or
      similar)

    - need a way to the site running the machine (e.g. a department
      in the company deploying PolicyKit) to ship policy files; these
      files override OS vendor and site-provided files. Again, installed
      via RPMs (or similar)

 o  Should be possible to configure authorizations for the local
    machine; this overrides what is provided by the OS vendor, org
    and site

    - we want a D-Bus API for doing this
      - Object:    /org/freedesktop/PolicyKit1/LocalAuthority
        Interface: org.freedesktop.PolicyKit1.LocalAuthority

    - (this replaces the existing AuthorityManager stuff in git master)

    - We want a command line tool, pklamanage, that uses the D-Bus API

    - In GNOME, we want a GTK+ based tool that uses the D-Bus API

    - configuring authorizations will in turn require authorization; we
      can conveniently use PolicyKit itself for this (and OS vendors,
      orgs and sites can thus completely lock this down)

 o  Authorization files provided by RPMs (or similar) should never be
    changed by doing local changes. So we need some kind of stacking
    like GConf has.

 o  Need more than just the ability to "grant" an authorization; e.g.
    we want to be able to do things like

    - for action, org.foo.xyz, always require admin auth (even if
      the defaults in the policy is "yes")

    - have negative authorizations - for example, if user U is member
      of the group G and everyone in G is authorized for the action
      org.foo.xyz, make it possible to say that U is not

The proposed solution is this. Files with authorization information will
be stored in ini-key like files (e.g. files parseable by GKeyFile). We
will use the following directory hierarchy

 /var/lib/polkit-1/localauthority/10-osvendor.d/
                                  20-org.d/
                                  30-site.d/
                                  99-local.d/

Files in each directory

 - MUST have the .pkla suffix
 - SHOULD use a unique name using reverse DNS style, e.g.
    org.fedoraproject.fedora.desktop-spin.pkla

and may contain zero or more entries like this

 [ATA SMART]
 Version=1
 Identity=unix-group:desktop-user;unix-group:desktop-admin
 Action=org.freedesktop.devkit-disks.drive-ata-smart*
 Result=yes

where

 [ATA SMART]  :  Name of the authorization; must be unique for
                 the file
 Version      :  The version of the authorization format (so we can make
                 incompatible changes later on without breaking stuff)
 Identity     :  A semicolon separated list of identities for which the
                 authorization applies. Globs can be used to match
                 multiple identities
 Action       :  A glob (cf. glob(3)) for matching actions
 Result       :  What to return, see [1]

The snippet above basically says that any user in the UNIX group
'desktop-user' and 'desktop-admin' is authorized for any action that
matches the org.freedesktop.devkit-disks.drive-ata-smart* glob.

Another example is this

 [Deny All]
 Version=1
 Identity=unix-user:*
 Action=*
 Result=no

that denies everything. Or

 [Paranoid]
 Version=1
 Identity=unix-user:*
 Action=*
 Result=auth_admin

that requires admin authentication for everything.

The plan I have in mind for Fedora (and GNOME) is that we will be
providing a number of RPMs such as

 polkit-desktop-policy.noarch.rpm
 polkit-kiosk-policy.noarch.rpm
 polkit-server-policy.noarch.rpm
 polkit-denyall-policy.noarch.rpm

all providing polkit-policy so you can only have one of them installed
at the same time. Each RPM will contain authorization configuration that
matches the usage scenario. 

Specifically for the polkit-desktop-policy we want to configure things
in a way so the authentication prompts are very rarely shown. This
includes introducing a couple of UNIX groups

    pk-desktop-guest
    pk-desktop-user
    pk-desktop-power-user

where

 - pk-desktop-guest: a very restricted account; we lock down all
                     actions here and punch a few holes

 - pk-desktop-user:  full access to change timezone / manage most
                     hardware; install trusted software

 - pk-desktop-power-user: install software / add/remove users

Managing things this way allows you to very easily integrate this into
the user account editor effort (which is stalled at the moment, grr) as
described here

https://www.redhat.com/archives/fedora-desktop-list/2008-May/msg00006.html

E.g. the basic idea is that we can have a very simple User Interface
that adds/removes capabilities to a certain user account.

Also, as the OS evolves and new PolicyKit actions are added, we simply
just update the polkit-desktop-policy.noarch.rpm to include the new
actions. For example, if, say, someone adds a new framework to control
the firewall in F12 or F13, we can grant the needed authorizations to
the pk-desktop-* groups in order to make them use their system without
having to endure useless authentication dialogs.

--

Any feedback more than welcome. I will start working on this in a couple
of days. I will send more updates to the list as I progress.

     David

[1] : Description of Result in .pkla files is basically what we already
put in .policy files. See

 http://hal.freedesktop.org/docs/polkit/PolicyKit-1.8.html

for the possible values. E.g. "no", "yes", "auth_self", "auth_admin",
"auth_self_keep", "auth_admin_keep".