libvirt users - May 2018 - Re: Libvirt access control drivers

On Wed, May 09, 2018 at 10:00:19AM +0100, Daniel P. Berrangé
wrote:
> On Wed, May 09, 2018 at 11:50:33AM +0300, Anastasiya Ruzhanskaya wrote:
> > Here https://libvirt.org/acl.html is stated that you designed this
access
> > control system as pluggable. Are there any options ( even with
modifying
> > libvirt code) to plug in any custom driver?
> > I just need to take a try and design something that will support
remote
> > access control.
> > I am not sure if sVirt is the right thing I should look at.
> 
> It is pluggable in the sense that we can write more backends for it
> without having to refactor the rest of libvirt codebase. It isn't
> pluggable from POV of an end user wishing to change it - it needs
> contribution to libvirt code to add more options.
> 
> I did look at creating an SELinux plugin many years ago, but the
> number of new SELinux AVs to be defined was huge and I wasn't sure
> the complexity of policy would be practical to handle in real world.
> Also, SELinux with TCP adds an extra level of complexity as you now
> need to figure out IPSec setup to pass SELinux labels across the
> network from the client.
> 
> Probably what we would more usefully add is a simple RBAC based
> module natively in libvirt.
I forgot to say that if you want to look at writing a new impl the code
is kept in $GIT/src/access/.

The current polkit impl is viraccessdriverpolkit.c. Implementing a new
driver involves creating a new source file with a virAccessDriver
struct that contains pointers to the methods that implement the desired
logic.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Great, thanks for pointing this out. I will certainly look at it.

2018-05-09 14:41 GMT+03:00 Daniel P. Berrangé <berrange@redhat.com>:
> On Wed, May 09, 2018 at 10:00:19AM +0100, Daniel P. Berrangé wrote:
> > On Wed, May 09, 2018 at 11:50:33AM +0300, Anastasiya Ruzhanskaya
wrote:
> > > Here https://libvirt.org/acl.html is stated that you designed
this
> access
> > > control system as pluggable. Are there any options ( even with
> modifying
> > > libvirt code) to plug in any custom driver?
> > > I just need to take a try and design something that will support
remote
> > > access control.
> > > I am not sure if sVirt is the right thing I should look at.
> >
> > It is pluggable in the sense that we can write more backends for it
> > without having to refactor the rest of libvirt codebase. It isn't
> > pluggable from POV of an end user wishing to change it - it needs
> > contribution to libvirt code to add more options.
> >
> > I did look at creating an SELinux plugin many years ago, but the
> > number of new SELinux AVs to be defined was huge and I wasn't sure
> > the complexity of policy would be practical to handle in real world.
> > Also, SELinux with TCP adds an extra level of complexity as you now
> > need to figure out IPSec setup to pass SELinux labels across the
> > network from the client.
> >
> > Probably what we would more usefully add is a simple RBAC based
> > module natively in libvirt.
>
> I forgot to say that if you want to look at writing a new impl the code
> is kept in $GIT/src/access/.
>
> The current polkit impl is viraccessdriverpolkit.c. Implementing a new
> driver involves creating a new source file with a virAccessDriver
> struct that contains pointers to the methods that implement the desired
> logic.
>
>
> Regards,
> Daniel
> --
> |: https://berrange.com      -o-    https://www.flickr.com/photos/
> dberrange :|
> |: https://libvirt.org         -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/
> dberrange :|
>

Excuse me for renewing this discussion, but I am curious if you would add
new module, which will be able to process users not based on unix
processes, from where do you plan to get usernames? I mean, virt-manager
could give them, as there is authentication in GUI, but for example when
using oVirt, none of the usernames reach libvirt through the communication
between server and nodes.


2018-05-09 14:46 GMT+03:00 Anastasiya Ruzhanskaya <
anastasiya.ruzhanskaya@frtk.ru>:
> Great, thanks for pointing this out. I will certainly look at it.
>
> 2018-05-09 14:41 GMT+03:00 Daniel P. Berrangé <berrange@redhat.com>:
>
>> On Wed, May 09, 2018 at 10:00:19AM +0100, Daniel P. Berrangé wrote:
>> > On Wed, May 09, 2018 at 11:50:33AM +0300, Anastasiya Ruzhanskaya
wrote:
>> > > Here https://libvirt.org/acl.html is stated that you designed
this
>> access
>> > > control system as pluggable. Are there any options ( even
with
>> modifying
>> > > libvirt code) to plug in any custom driver?
>> > > I just need to take a try and design something that will
support
>> remote
>> > > access control.
>> > > I am not sure if sVirt is the right thing I should look at.
>> >
>> > It is pluggable in the sense that we can write more backends for
it
>> > without having to refactor the rest of libvirt codebase. It
isn't
>> > pluggable from POV of an end user wishing to change it - it needs
>> > contribution to libvirt code to add more options.
>> >
>> > I did look at creating an SELinux plugin many years ago, but the
>> > number of new SELinux AVs to be defined was huge and I wasn't
sure
>> > the complexity of policy would be practical to handle in real
world.
>> > Also, SELinux with TCP adds an extra level of complexity as you
now
>> > need to figure out IPSec setup to pass SELinux labels across the
>> > network from the client.
>> >
>> > Probably what we would more usefully add is a simple RBAC based
>> > module natively in libvirt.
>>
>> I forgot to say that if you want to look at writing a new impl the code
>> is kept in $GIT/src/access/.
>>
>> The current polkit impl is viraccessdriverpolkit.c. Implementing a new
>> driver involves creating a new source file with a virAccessDriver
>> struct that contains pointers to the methods that implement the desired
>> logic.
>>
>>
>> Regards,
>> Daniel
>> --
>> |: https://berrange.com      -o-    https://www.flickr.com/photos/
>> dberrange :|
>> |: https://libvirt.org         -o-
>> https://fstop138.berrange.com :|
>> |: https://entangle-photo.org    -o-    https://www.instagram.com/dber
>> range :|
>>
>
>