[libvirt-users] Libvirt access control drivers

[Anastasiya Ruzhanskaya]

Hello!
According to the documentation access control drivers are not in really
"good condition". There is a polkit, but it can distinguish users only
according the pid. However, I have met some articles about more
fine-grained control and about selinux drivers for libvirt? So, what is the
status now? Should I implement something by myself if I want access based
on login, are their instructions how to write these drivers or there is
smth already?

[Daniel P. Berrangé]

Post by Anastasiya Ruzhanskaya
Hello!
According to the documentation access control drivers are not in really
"good condition". There is a polkit, but it can distinguish users only
according the pid. However, I have met some articles about more
fine-grained control and about selinux drivers for libvirt? So, what is the
status now? Should I implement something by myself if I want access based
on login, are their instructions how to write these drivers or there is
smth already?

The polkit access control driver is the only one we support, and it is not
something that end users can replace as this is not a public plugin system.
Any alternate impl would have to be part of libvirt core.

I'm not sure what docs you are referring to, but the polkit driver is in
perfectly good condition. It is not restricted to just checking PIDs,
in fact PID is largely irrelevant - user name and group membership are
the important things to check. Ther is an example in the source tree at
examples/polkit/libvirt-acl.rules showing a simple RBAC approach to using
polkit.

Regards,
Daniel

[Anastasiya Ruzhanskaya]

I read this page https://libvirt.org/aclpolkit.html
And it is written :"At this point in time, the only attribute provided by
libvirt to identify the user invoking the operation is the PID of the
client program. This means that the polkit access control driver is only
useful if connections to libvirt are restricted to its UNIX domain socket."

Post by Daniel P. Berrangé

Post by Anastasiya Ruzhanskaya
Hello!
According to the documentation access control drivers are not in really
"good condition". There is a polkit, but it can distinguish users only
according the pid. However, I have met some articles about more
fine-grained control and about selinux drivers for libvirt? So, what is

the

Post by Anastasiya Ruzhanskaya
status now? Should I implement something by myself if I want access based
on login, are their instructions how to write these drivers or there is
smth already?

The polkit access control driver is the only one we support, and it is not
something that end users can replace as this is not a public plugin system.
Any alternate impl would have to be part of libvirt core.
I'm not sure what docs you are referring to, but the polkit driver is in
perfectly good condition. It is not restricted to just checking PIDs,
in fact PID is largely irrelevant - user name and group membership are
the important things to check. Ther is an example in the source tree at
examples/polkit/libvirt-acl.rules showing a simple RBAC approach to using
polkit.
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 :|

[Anastasiya Ruzhanskaya]

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)?

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

[Daniel P. Berrangé]

Post by Anastasiya Ruzhanskaya
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.
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)?

OpenStack has user information associated with VMs it is running, but it
would be hard to pass this to libvirt because a single connection is
used to manager many different users' VMs.

Regards,
Daniel

[Anastasiya Ruzhanskaya]

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?

Post by Anastasiya Ruzhanskaya

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

[Daniel P. Berrangé]

Post by Anastasiya Ruzhanskaya
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?

Libvirt authentication happens when a connection is opened - oVirt doesn't
open a connection for each user. So you have to have a way to authenticate
the initial connection, and then authorize individual APIs made on it.

Regards,
Daniel

[Anastasiya Ruzhanskaya]

Hello!
I still want to clarify one question. Instead of making authentication of
oVirt and then impersonation of each user, oVirt can just pass user
information inside messages and libvirt at the end can read this user
information inside rpc messages (perhaps user login could be written in one
of string fields in RPC message, simply login = <...> inside message). Why
this (assume that it is possible to implement this for everyone) will not
work?

Post by Daniel P. Berrangé

Post by Anastasiya Ruzhanskaya
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

Post by Anastasiya Ruzhanskaya
user?

Libvirt authentication happens when a connection is opened - oVirt doesn't
open a connection for each user. So you have to have a way to authenticate
the initial connection, and then authorize individual APIs made on it.
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 :|

[Erik Skultety]

Post by Anastasiya Ruzhanskaya
Hello!
I still want to clarify one question. Instead of making authentication of
oVirt and then impersonation of each user, oVirt can just pass user
information inside messages and libvirt at the end can read this user

Bypassing libvirt API and sending RPC messages to libvirtd is strongly
discouraged and oVirt wouldn't do that, besides, when the libvirtd deserializes
the RPC message it will eventually call the same public API entry point that
was used on the client side, but delegating it to a different driver (remote vs
qemu for example). Knowing that, how would you pass this extra information
to the existing API without changing it?

Post by Anastasiya Ruzhanskaya
information inside rpc messages (perhaps user login could be written in one
of string fields in RPC message, simply login = <...> inside message). Why

Changes to the RPC protocol would result in backwards incompatibility.

Erik

Post by Anastasiya Ruzhanskaya
this (assume that it is possible to implement this for everyone) will not
work?

[Anastasiya Ruzhanskaya]

Hello!
Excuse me for renewing this discussion.
You mentioned that you can't send identity information over the remote
channel in libvirt.
In virt-manager, which directly uses libvirt remote functionality, there
are such fields (attached, "username").
What they are used for? Are they used somehow in the sent packets?

Ok, excuse me for misunderstanding, how it is possible then to set up
access control when I use remote connection to KVM ( not in UNIX domain)?
Is there any way within libvirt, maybe based on authentication or
certificates?

Unfortunately we don't have a solution for fine grained access control
when using remote TCP access. We had a feature request against polkit
to allow passing it identity information such as certificate distinguished
name, but that was rejected :-(
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 :|