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
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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
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
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
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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
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
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
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:
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
openlmi-devel@lists.stg.fedorahosted.org