Possibility of adding remote subject type for authorization

[Martin Kletzander]

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