Possibility of adding remote subject type for authorization

Martin Kletzander mkletzan at redhat.com
Thu Nov 25 13:29:59 UTC 2021


Also feel free to let me know if creating an issue on GitLab is the
preferred way of interaction for these kind of ideas/suggestions.

Thank you

On Tue, Nov 23, 2021 at 05:36:24PM +0100, Martin Kletzander wrote:
>Hello,
>
>we are using polkit in libvirt for fine grained ACLs when users want to
>perform various tasks when connected to the libvirt daemon over a unix
>socket.
>
>We can only use polkit for such fine-grained ACLs when we can represent
>the connected user (or application) as a polkit subject, which
>unfortunately limits us to local connections only.  We are currently
>creating subjects with `subject_kind` set to "unix_process" with keys of
>`uid`, `pid` and `start-time`.
>
>However libvirt also offers its functionality over remote connections,
>for example of a TLS connection and also possibly with SASL
>authentication.
>
>I would like to add support for fine-grained ACLs over remote
>connections as well and given the fact that we already have polkit
>support and its rules have the most flexibility, I would like to use
>that to my advantage.
>
>So I had an idea, but I also thought of some possible issues with the
>approach, so I will detail them here.
>
>The idea was that we would use the same CheckAuthorization polkit API to
>"check the authorization" and we would create a new `subject_kind`,
>something like "remote_user", add fields like Distinguished Name from a
>client's x509 certificate used for the TLS connection and/or SASL
>username/authname from the SASL handshake.  In both cases it would only
>be used for the authorization, authentication would be dealt with in the
>daemon itself.
>
>The possible issues I was worried about were mainly:
>
>  - Maybe there's some policy somewhere saying that polkit wants to only
>    deal with local rules.  I have not found anything like that, but that
>    does not mean it does not exist ;)
>
>  - Current rules could have a changed semantics.  I hope they would not
>    since the subject could have unset 'id', make it not be part of any
>    group etc.  Unfortunately I did not dig into that part deep enough
>    hoping that people on this list will know the answer faster than me
>    trying to research it all.
>
>  - The specification would need to change.  However I believe polkit is
>    designed to be extensible and this should not really be a huge
>    issue, hopefully.
>
>I think all these are solvable, I am willing to put the effort in to
>make this change, but I would like to know this will not be dismissed as
>otherwise I will rather put the effort into creating another access
>driver in our project.
>
>Feedback is very appreciated, have a nice day.
>
>Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/polkit-devel/attachments/20211125/920b3db5/attachment.sig>


More information about the polkit-devel mailing list