Polkit-based authorization in OpenLMI providers

[Jan Safranek]

Hello,

I've been working on reusing polkit authorization for OpenLMI providers,
which use a DBus service (e.g. NetworkManager, PackageKit, realmd,
systemd, ...).

I've documented the architecture on our wiki [1] and I submitted review
in our review-board. I won't push the patches until we get to an
agreement that it's the way to go and also the implementation is secure
- please review carefully. There are *no* changes needed in our provider
code and/or in the DBus services we work with.

1: https://fedorahosted.org/openlmi/wiki/PolkitAuthorization
2: https://reviewboard-openlmi.rhcloud.com/users/jsafrane/

In short, the concept is similar to Cockpit's reauthorization [3], we
just don't play tricks with user passwords - we don't have one on CIM
provider level. Instead, we register a polkit agent, which bluntly
authenticates every request from polkit in its PAM session.

3: https://github.com/cockpit-project/cockpit/blob/master/doc/reauthorize.md

[Kudos to Cockpit guys, I used their code to implement polkit agent and
helper.]

Just a side note: right now, users with remote CIM access must be
members of 'pegasus' group, otherwise they cannot start a provider. Is
it good or bad? Should _any_ user be able to use CIM by default and let
polkit decide? It's trivial to fix, just set different file/directory
permissions in tog-pegasus.rpm. And there is /etc/Pegasus/access.conf,
which can control access properly if sysadmin wishes, so the question is
just about the default setting.


Jan

[Radek Novacek]

Hi,

this is really great job.

I have one question that came to my mind:

What happens when there is already a polkit agent running in the system?

Let's say I'm connecting to pegasus on my desktop computer where polkit-kde-
authentication-agent-1 is already running as part of desktop session. Is it 
possible to have multiple agents running? Which one will be used to 
authenticate the request?

Radek

On Thu 17 of Jul 2014 10:38:29 Jan Safranek wrote:
>  Hello,
>  
>  I've been working on reusing polkit authorization for OpenLMI providers,
>  which use a DBus service (e.g. NetworkManager, PackageKit, realmd,
>  systemd, ...).
>  
>  I've documented the architecture on our wiki [1] and I submitted review
>  in our review-board. I won't push the patches until we get to an
>  agreement that it's the way to go and also the implementation is secure
>  - please review carefully. There are *no* changes needed in our provider
>  code and/or in the DBus services we work with.
>  
>  1: https://fedorahosted.org/openlmi/wiki/PolkitAuthorization
>  2: https://reviewboard-openlmi.rhcloud.com/users/jsafrane/
>  
>  In short, the concept is similar to Cockpit's reauthorization [3], we
>  just don't play tricks with user passwords - we don't have one on CIM
>  provider level. Instead, we register a polkit agent, which bluntly
>  authenticates every request from polkit in its PAM session.
>  
>  3: https://github.com/cockpit-project/cockpit/blob/master/doc/reauthorize.md
>  
>  [Kudos to Cockpit guys, I used their code to implement polkit agent and
>  helper.]
>  
>  Just a side note: right now, users with remote CIM access must be
>  members of 'pegasus' group, otherwise they cannot start a provider. Is
>  it good or bad? Should _any_ user be able to use CIM by default and let
>  polkit decide? It's trivial to fix, just set different file/directory
>  permissions in tog-pegasus.rpm. And there is /etc/Pegasus/access.conf,
>  which can control access properly if sysadmin wishes, so the question is
>  just about the default setting.
>  
>  
>  Jan
>  
>  _______________________________________________
>  openlmi-devel mailing list
>  openlmi-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel

[Jan Safranek]

On 07/17/2014 10:55 AM, Radek Novacek wrote:
>  Hi,
>  
>  this is really great job.
>  
>  I have one question that came to my mind:
>  
>  What happens when there is already a polkit agent running in the system?
>  
>  Let's say I'm connecting to pegasus on my desktop computer where polkit-kde-
>  authentication-agent-1 is already running as part of desktop session. Is it 
>  possible to have multiple agents running? Which one will be used to 
>  authenticate the request? 
That's why our lmipolkitagent starts a new PAM session for a provider
process. Each polkit agent is bound to a PAM session, therefore our
polkit agent is used only for descendants of our CIM provider process
and does not interfere with existing desktop or console polkit agents.

Jan

[Radek Novacek]

On Thu 17 of Jul 2014 13:29:23 Jan Safranek wrote:
>  On 07/17/2014 10:55 AM, Radek Novacek wrote:
>  > Hi,
>  > 
>  > this is really great job.
>  > 
>  > I have one question that came to my mind:
>  > 
>  > What happens when there is already a polkit agent running in the system?
>  > 
>  > Let's say I'm connecting to pegasus on my desktop computer where
>  > polkit-kde- authentication-agent-1 is already running as part of desktop
>  > session. Is it possible to have multiple agents running? Which one will
>  > be used to authenticate the request?
>  
>  That's why our lmipolkitagent starts a new PAM session for a provider
>  process. Each polkit agent is bound to a PAM session, therefore our
>  polkit agent is used only for descendants of our CIM provider process
>  and does not interfere with existing desktop or console polkit agents.
>  
>  Jan 
Ah, I've missed that. Thanks for the explanation, it sounds reasonable.

Radek

[Russell Doty]

On Thu, 2014-07-17 at 10:38 +0200, Jan Safranek wrote:
>  Hello,
>  
>  I've been working on reusing polkit authorization for OpenLMI providers,
>  which use a DBus service (e.g. NetworkManager, PackageKit, realmd,
>  systemd, ...). 
Jan, can customers modify or create access policies or is this
hardcoded
into the Providers?

>  
>  I've documented the architecture on our wiki [1] and I submitted review
>  in our review-board. I won't push the patches until we get to an
>  agreement that it's the way to go and also the implementation is secure
>  - please review carefully. There are *no* changes needed in our provider
>  code and/or in the DBus services we work with.
>  
>  1: https://fedorahosted.org/openlmi/wiki/PolkitAuthorization
>  2: https://reviewboard-openlmi.rhcloud.com/users/jsafrane/
>  
>  In short, the concept is similar to Cockpit's reauthorization [3], we
>  just don't play tricks with user passwords - we don't have one on CIM
>  provider level. Instead, we register a polkit agent, which bluntly
>  authenticates every request from polkit in its PAM session.
>  
>  3: https://github.com/cockpit-project/cockpit/blob/master/doc/reauthorize.md
>  
>  [Kudos to Cockpit guys, I used their code to implement polkit agent and
>  helper.]
>  
>  Just a side note: right now, users with remote CIM access must be
>  members of 'pegasus' group, otherwise they cannot start a provider. Is
>  it good or bad? Should _any_ user be able to use CIM by default and let
>  polkit decide? It's trivial to fix, just set different file/directory
>  permissions in tog-pegasus.rpm. And there is /etc/Pegasus/access.conf,
>  which can control access properly if sysadmin wishes, so the question is
>  just about the default setting.
>  
>  
>  Jan
>  
>  _______________________________________________
>  openlmi-devel mailing list
>  openlmi-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel

[Jan Safranek]

On 07/21/2014 07:57 PM, Russell Doty wrote:
>  On Thu, 2014-07-17 at 10:38 +0200, Jan Safranek wrote:
> > Hello,
> >
> > I've been working on reusing polkit authorization for OpenLMI providers,
> > which use a DBus service (e.g. NetworkManager, PackageKit, realmd,
> > systemd, ...).
>  Jan, can customers modify or create access policies or is this hardcoded
>  into the Providers? 
People can freely modify the policy, it's just bunch of files in
/etc/polkit-1. By default, the policy is empty and the default one
applies, in Fedora it means that members of 'wheel' group are de-facto
sysadmins and can do anything.

Just FYI, the policy files in /etc are javascript, which brings great
flexibility (jsafrane can set locale only on Monday and only when it's
not raining), on the other hand, there is no way, how to edit these
files from API (you would need to parse full javascript semantics).


Jan

[Jan Safranek]

I am pushing the patches to devel/polkit branch in our git repositories.
Also, I created ticked to track progress:

https://fedorahosted.org/openlmi/ticket/321

There is still some work to do.

Jan

[Jan Safranek]

On 07/24/2014 05:58 PM, Jan Safranek wrote:
>  I am pushing the patches to devel/polkit branch in our git
> repositories.
>  Also, I created ticked to track progress:
>  
>  https://fedorahosted.org/openlmi/ticket/321 
I updated all the devel/polkit branches to appropriate git masters. The
only real missing part is polkit authorization for account service.
Since there is no usable DBus service for management of groups,
volunteers are needed to implement a new one. Perhaps with cooperation
with SSSD

https://fedorahosted.org/sssd/.

Until it is implemented it makes little sense to merge OpenLMI polkit
patches to master.

I am closing appropriate ReviewBoard reviews.

Jan