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

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 :|
>>
>
>

On Fri, May 11, 2018 at 04:26:36PM +0300, Anastasiya Ruzhanskaya
wrote:
> 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.
The identity attributes would have to use information that libvirt acquires
from its authentication modules.  When using TLS, if client certificates are
requested by libvirtd, then we can check the x509 cert distinguished name
field.  When using SASL,  if the SASL mechanism returns a username, we can
check that.

NB, we would *not* be trying to check the end user that oVirt knows about,
rather we are authenticating oVirt itself.

To check end users defined by the higher level mgmt app would require an
extra set of functionality in the public API, to allow oVirt to do user
impersonation with libvirt.  eg libvirt would first authenticate ovirt,
ovirt would then sya it wants to impersonate "fred" and from there all
APIs get checked against "fred".

This gets pretty difficult though, because oVirt and most similar mgmt
apps generally only have a single connection to libvirt but are doing
work for 100's of different users on it. So in reality it is not very
practical for libvirt to try to validate ovirt's users.

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 :|

I see. I also know OpenStack uses libvirt, nova-compute has a driver for
communication.
I have briefly looked through these 10 thousand lines of code in overall on
github for openstack's libvirt driver and didn't notice any user info as
well.
To make the picture full don't you know is there the same scheme there:
some high level openstack api with user information and passing only
actions to libvirt? Or nova-compute may carry some user info to libvirt
though it's interfaces ( which you then could use in your future role-based
module)?

2018-05-11 16:37 GMT+03:00 Daniel P. Berrangé <berrange@redhat.com>:
> On Fri, May 11, 2018 at 04:26:36PM +0300, Anastasiya Ruzhanskaya wrote:
> > 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.
>
> The identity attributes would have to use information that libvirt acquires
> from its authentication modules.  When using TLS, if client certificates
> are
> requested by libvirtd, then we can check the x509 cert distinguished name
> field.  When using SASL,  if the SASL mechanism returns a username, we can
> check that.
>
> NB, we would *not* be trying to check the end user that oVirt knows about,
> rather we are authenticating oVirt itself.
>
> To check end users defined by the higher level mgmt app would require an
> extra set of functionality in the public API, to allow oVirt to do user
> impersonation with libvirt.  eg libvirt would first authenticate ovirt,
> ovirt would then sya it wants to impersonate "fred" and from
there all
> APIs get checked against "fred".
>
> This gets pretty difficult though, because oVirt and most similar mgmt
> apps generally only have a single connection to libvirt but are doing
> work for 100's of different users on it. So in reality it is not very
> practical for libvirt to try to validate ovirt's users.
>
> 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 :|
>

I actually didn't quite catch,why oVirt can't just pass user information
and you could check against it? This may require to create some
configuration files for libvirt about end users.
What is a advantage of authenticating oVirt, and then impersonation for end
user?

2018-05-11 16:37 GMT+03:00 Daniel P. Berrangé <berrange@redhat.com>:
> On Fri, May 11, 2018 at 04:26:36PM +0300, Anastasiya Ruzhanskaya wrote:
> > 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.
>
> The identity attributes would have to use information that libvirt acquires
> from its authentication modules.  When using TLS, if client certificates
> are
> requested by libvirtd, then we can check the x509 cert distinguished name
> field.  When using SASL,  if the SASL mechanism returns a username, we can
> check that.
>
> NB, we would *not* be trying to check the end user that oVirt knows about,
> rather we are authenticating oVirt itself.
>
> To check end users defined by the higher level mgmt app would require an
> extra set of functionality in the public API, to allow oVirt to do user
> impersonation with libvirt.  eg libvirt would first authenticate ovirt,
> ovirt would then sya it wants to impersonate "fred" and from
there all
> APIs get checked against "fred".
>
> This gets pretty difficult though, because oVirt and most similar mgmt
> apps generally only have a single connection to libvirt but are doing
> work for 100's of different users on it. So in reality it is not very
> practical for libvirt to try to validate ovirt's users.
>
> 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 :|
>