F20 Self Contained Change: Role based access control with libvirt

[Jaroslav Reznik]

= Proposed Self Contained Change: Role based access control with libvirt =
https://fedoraproject.org/wiki/Changes/Virt_ACLs

Change owner(s):  Daniel P. Berrange <berrange(a)redhat.com&gt;, Cole Robinson 
<crobinso(a)redhat.com&gt;

Allow role based access control with libvirt. 

== Detailed description ==
Libvirt role based access control will allow fine grained access control like 
'user FOO can only start/stop/pause vm BAR', but for all libvirt APIs and 
objects. 

== Scope ==
Proposal owners: 
* 90% of the work is already in rawhide
* Documentation needs to be written 

Other developers: N/A (not a System Wide Change)
Release engineering: N/A (not a System Wide Change)
Policies and guidelines: N/A (not a System Wide Change) 
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

[Kevin Fenzi]

On Mon, 15 Jul 2013 12:00:35 +0200
Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:

>  = Proposed Self Contained Change: Role based access control with
>  libvirt = https://fedoraproject.org/wiki/Changes/Virt_ACLs
>  
>  Change owner(s):  Daniel P. Berrange <berrange(a)redhat.com&gt;, Cole
>  Robinson <crobinso(a)redhat.com&gt;
>  
>  Allow role based access control with libvirt. 
>  
>  == Detailed description ==
>  Libvirt role based access control will allow fine grained access
>  control like 'user FOO can only start/stop/pause vm BAR', but for all
>  libvirt APIs and objects. 
>  
>  == Scope ==
>  Proposal owners: 
>  * 90% of the work is already in rawhide
>  * Documentation needs to be written 
>  
>  Other developers: N/A (not a System Wide Change)
>  Release engineering: N/A (not a System Wide Change)
>  Policies and guidelines: N/A (not a System Wide Change)  
How do you set these policies? Is there a command/gui/interface? Or a
text file? Or ?

I can't seem to see any docs off the change page off hand. 

kevin

[Daniel P. Berrange]

On Mon, Jul 15, 2013 at 10:06:30AM -0600, Kevin Fenzi wrote:
>  On Mon, 15 Jul 2013 12:00:35 +0200
>  Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:
>  
>  > = Proposed Self Contained Change: Role based access control with
>  > libvirt = https://fedoraproject.org/wiki/Changes/Virt_ACLs
>  > 
>  > Change owner(s):  Daniel P. Berrange <berrange(a)redhat.com&gt;, Cole
>  > Robinson <crobinso(a)redhat.com&gt;
>  > 
>  > Allow role based access control with libvirt. 
>  > 
>  > == Detailed description ==
>  > Libvirt role based access control will allow fine grained access
>  > control like 'user FOO can only start/stop/pause vm BAR', but for all
>  > libvirt APIs and objects. 
>  > 
>  > == Scope ==
>  > Proposal owners: 
>  > * 90% of the work is already in rawhide
>  > * Documentation needs to be written 
>  > 
>  > Other developers: N/A (not a System Wide Change)
>  > Release engineering: N/A (not a System Wide Change)
>  > Policies and guidelines: N/A (not a System Wide Change) 
>  
>  How do you set these policies? Is there a command/gui/interface? Or a
>  text file? Or ? 
It is done via the standard PolicyKit javascript auth rules files

>  I can't seem to see any docs off the change page off hand. 
The docs have not been written yet. That's out of the outstanding work
items to be done for F20.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

[Matthew Miller]

On Mon, Jul 15, 2013 at 05:09:33PM +0100, Daniel P. Berrange wrote:
>  > How do you set these policies? Is there a command/gui/interface?
> Or a
>  > text file? Or ?
>  It is done via the standard PolicyKit javascript auth rules files 
How does this fit with the PolicyKit documentation for javascript auth
rules, which declares

       Authorization rules are intended for two specific audiences

       ·   System Administrators

       ·   Special-purpose Operating Systems / Environments

       and those audiences only. In particular, applications, mechanisms and
       general-purpose operating systems must never include any
       authorization rules.

?


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Daniel P. Berrange]

On Mon, Jul 15, 2013 at 12:34:55PM -0400, Matthew Miller wrote:
>  On Mon, Jul 15, 2013 at 05:09:33PM +0100, Daniel P. Berrange wrote:
>  > > How do you set these policies? Is there a command/gui/interface? Or a
>  > > text file? Or ?
>  > It is done via the standard PolicyKit javascript auth rules files
>  
>  How does this fit with the PolicyKit documentation for javascript auth
>  rules, which declares
>  
>         Authorization rules are intended for two specific audiences
>  
>         ·   System Administrators
>  
>         ·   Special-purpose Operating Systems / Environments
>  
>         and those audiences only. In particular, applications, mechanisms and
>         general-purpose operating systems must never include any
>         authorization rules.
>  
>  ? 
What/where's the problem you're seeing ?

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

[Matthew Miller]

On Mon, Jul 15, 2013 at 05:37:26PM +0100, Daniel P. Berrange wrote:
>  >        and those audiences only. In particular, applications,
> mechanisms
>  >        and general-purpose operating systems must never include any
>  >        authorization rules.
>  What/where's the problem you're seeing ? 
Not necessarily a problem -- just a clarification, which I guess I should
have been more clear on myself. :) This is just changing libvirt so that
these auth policy files will work, not shipping any, right?

(I also find this restriction puzzling in the first place, but that's
another issue.)

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Daniel P. Berrange]

On Mon, Jul 15, 2013 at 12:58:36PM -0400, Matthew Miller wrote:
>  On Mon, Jul 15, 2013 at 05:37:26PM +0100, Daniel P. Berrange wrote:
>  > >        and those audiences only. In particular, applications, mechanisms
>  > >        and general-purpose operating systems must never include any
>  > >        authorization rules.
>  > What/where's the problem you're seeing ?
>  
>  Not necessarily a problem -- just a clarification, which I guess I should
>  have been more clear on myself. :) This is just changing libvirt so that
>  these auth policy files will work, not shipping any, right? 
Yes, libvirt is just calling pkcheck with suitable arguments. The admin
is the one writing the policy files, which is what we need to document
the process for.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

[Matthew Miller]

On Mon, Jul 15, 2013 at 06:03:46PM +0100, Daniel P. Berrange wrote:
>  Yes, libvirt is just calling pkcheck with suitable arguments. The
> admin
>  is the one writing the policy files, which is what we need to document
>  the process for. 
Ok cool.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[James Hogarth]

>         Authorization rules are intended for two specific audiences
>
>         ·   System Administrators
>  
Well one could argue with good conscience that starting, stopping and so on
of VMs is a system administration function and this viable for policykit
based configuration...

Policykit as already used for local KVM (which naturally includes SSH
transport) if available so it keeps things consistent as well...