Local Authority plan
Dario Freddi
drf54321 at gmail.com
Fri Jun 26 01:26:51 PDT 2009
Hey David,
I won't answer in blocks since your mail was pretty long and clear. First
things first, what you described seems great. Although, I have a couple of
questions.
Basically, your structure of preferences is the following
10-osvendor
20-org/site
99-user
However, I believe 10 and 20 should be inverted. I mean, in my vision we have
the following situation
- Developer A develops a Polkit based application, and defines some default
policies
- Distribution B believes that policies set by A are not really fitting their
way of doing things, so it puts its own pkla in the upper level
- The user, again, overrides it
If that's what you meant, I misunderstood you.
Then, for groups and stuff, it would be really nice to integrate this is the
polkit-authorization manager. I mean, at the moment you can define Everyone-
Active Console, etc. It would be nice if one could set the group permission as
well. Also, you didn't talk/I didn't see anything related to ConsoleKit.
Having a distinction between the Active/Inactive console is quite fundamental
in my opinion: how will you take care of this matter with .pkla? Also, are
.policy files going to disappear in favor of .pkla?
On Friday 26 June 2009 00:29:13 David Zeuthen wrote:
> 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".
>
>
> _______________________________________________
> polkit-devel mailing list
> polkit-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/polkit-devel
--
-------------------
Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/polkit-devel/attachments/20090626/a51073bf/attachment.pgp
More information about the polkit-devel
mailing list