RFE: Allow for generic "subject" kinds with arbitrary metadata attributes

[vmihalko]

In GitLab by @bugzilla-migration on Apr 26, 2013, 16:02

Submitted by Daniel P. Berrange

Assigned to David Zeuthen @david

Link to original bug (#63961)

Description

If there is no local UNIX user, session or DBus bus name available, then polkit can't be used for authorization, because no subject data can be provided to polkit. For example when libvirtd daemon accepts clients over a TCP connection, none of the 3 subject kinds is usable. The TCP clients do, however, have plenty of metadata that can used to form a subject identity. For example a kerberos principal name (negotiated via SASL), or some other SASL username, or a TLS x509 distinguished name, or some arbitrary combination of all of these.

Even when authorizing local clients, the fixed subject kinds is unhelpful. For example, when libvirt runs SASL over its UNIX sockets, the subject can be identified both by its PID and a kerberos principal name / SASL username.

Rather than adding more specialized subject classes, it would be desirable to have a generic subject class which accepted arbitrary (key,value) attributes. Then standardize the names of attributes for various pieces of information such as PID, PID start time, session name, SASL username, etc. This allows an application using polkit to pass all identifying attributes it has for a subject, rather than having to decide between passing a PID vs a session name vs a SASL username, or something else.

[vmihalko]

In GitLab by @bugzilla-migration on Apr 26, 2013, 16:36

:speech_balloon: Miloslav Trmac said:

(All IMHO, and without spending that much time thinking about it.)

For handling remote subjects, and for the polkit configuration to make sense, subject identity should have meaning within the whole system without referring to a particular application (for example, an X.509 DN is suspect because it depends on what CA the application accepts). I can't see much value in moving application-specific authorization rules for application-specific subjects to the system-wide polkit service. Yes, there'd be a single place to configure "everything", but every application would still be configured differently.

Having a "domain" system that is configured system-wide and an uniform way to refer to subjects within that domain would be very vaulable (and it might allow us to start escaping the limitations of integer UIDs).

For local clients, I don't think applications are expected to do their own authentication, the IPC system together with polkit should handle it mostly transparently (as it does when the subject is a D-Bus endpoint). Would I be wrong in viewing SASL over AF_UNIX as a case of a "remote" subject that is only using a more optimized socket type? (Sure, without having support for remote subjects and SASL it doesn't help libvirt at this point.)

Having alternative subject identifications for a single connection has problematic semantics - what if the x509 cert (or local user account) is allowed but the SASL username is prohibited? I'd much prefer a "domain" model where the subject's identity is unambiguous and unique, possibly supporting several alternative ways to authenticate that identity, e.g. SASL, x.509, SCM_CREDS - but the result should be a single identity.

Arbitrary (key valure) pairs are generally a poor way to write an API. It is structurally non-ABI-breaking, fully compatible and fully extensible, but actually it tends to only move the ABI, compatibility and extensibility concerns from the language level (where we have automated tools to help) to the semantic level (where we don't and can't have such tools).

[vmihalko]

In GitLab by @bugzilla-migration on Apr 26, 2013, 17:38

:speech_balloon: Daniel P. Berrange said:

(In reply to comment 1) (All IMHO, and without spending that much time thinking about it.)

For handling remote subjects, and for the polkit configuration to make sense, subject identity should have meaning within the whole system without referring to a particular application (for example, an X.509 DN is suspect because it depends on what CA the application accepts).

It is easy to provide the x509 DN of the CA, alongside the DN of the subject, to provide the necessary scope for making the authorization decision. This doesn't make it application specific in any way.

                                                   I can't see much

value in moving application-specific authorization rules for application-specific subjects to the system-wide polkit service. Yes, there'd be a single place to configure "everything", but every application would still be configured differently.

I think you're understating the benefits of having a single place to configure all authorization. Also just as important as a single place, is having a single vocabulary for all authorization rules. The single location + vocabulary greatly simplifies life for both administrators & auditors, since they don't need to create tools to parser 1000's of application specific rules.

Furthermore, the point of using a library/protocol like SASL for the authentication is that the choice of authentication mechanism is delegated to the administrator. Thus the resulting subject identity attributes are in fact administrator defined, and explicitly not application specific.

For local clients, I don't think applications are expected to do their own authentication, the IPC system together with polkit should handle it mostly transparently (as it does when the subject is a D-Bus endpoint). Would I be wrong in viewing SASL over AF_UNIX as a case of a "remote" subject that is only using a more optimized socket type? (Sure, without having support for remote subjects and SASL it doesn't help libvirt at this point.)

I think you're trying to make a distinction that doesn't need to/shouldn't exist here. Polkit does not need to care about who has done the authentication, just that there has been some authentication process that has resulted in a subject identity with certain attributes. Ultimately the only things that need to care about the identity is the polkit backend + the administrator configuring this.

NB DBus itself could provide a SASL username, if someone defines an authorization mechanism for the DBus protocol that layered in SASL. Libvirt isn't using DBus here, it has an alternative IPC layer, but I don't think that should exclude it from using polkit for authorization. Having to having to re-invent the wheel for authorization itself would be a disservice to administrators IMHO.

Having alternative subject identifications for a single connection has problematic semantics - what if the x509 cert (or local user account) is allowed but the SASL username is prohibited? I'd much prefer a "domain" model where the subject's identity is unambiguous and unique, possibly supporting several alternative ways to authenticate that identity, e.g. SASL, x.509, SCM_CREDS - but the result should be a single identity.

You already have that problem today. A client process can be associated with a UID and a GID. What if the UID is allowed, but the GID is denied? The answer to such questions is simply up to the administrator defining the policy to decide. Via the polkit javascript rules files they can declare whether successful authorization requires both x509 cert + SASL username to be approved, or whether either one is sufficient on their own. There's no reason why you couldn't have a DBus client identified by a combination of a UID, GID and SASL username if DBus had a SASL auth mechanism layered in.

Arbitrary (key valure) pairs are generally a poor way to write an API. It is structurally non-ABI-breaking, fully compatible and fully extensible, but actually it tends to only move the ABI, compatibility and extensibility concerns from the language level (where we have automated tools to help) to the semantic level (where we don't and can't have such tools).

This is pretty much irrelevant FUD.

[vmihalko]

In GitLab by @bugzilla-migration on Apr 26, 2013, 18:20

:speech_balloon: Miloslav Trmac said:

(In reply to comment 2) I can't see much value in moving application-specific authorization rules for application-specific subjects to the system-wide polkit service. Yes, there'd be a single place to configure "everything", but every application would still be configured differently.

I think you're understating the benefits of having a single place to configure all authorization. Also just as important as a single place, is having a single vocabulary for all authorization rules. The single location + vocabulary greatly simplifies life for both administrators & auditors, since they don't need to create tools to parser 1000's of application specific rules.

I agree with that, however I'd like this to be simplified even more to the "domain" concept or something similar. I'd like not to end up with a authorization meta-framework (running arbitrary JavaScript) connecting other meta-frameworks (like SASL)...

For local clients, I don't think applications are expected to do their own authentication, the IPC system together with polkit should handle it mostly transparently (as it does when the subject is a D-Bus endpoint). Would I be wrong in viewing SASL over AF_UNIX as a case of a "remote" subject that is only using a more optimized socket type? (Sure, without having support for remote subjects and SASL it doesn't help libvirt at this point.)

I think you're trying to make a distinction that doesn't need to/shouldn't exist here. Polkit does not need to care about who has done the authentication, just that there has been some authentication process that has resulted in a subject identity with certain attributes.

Yes, polkit is separate from authentication shouldn't need to care about who has done the authentication. The result of authentication should be a "subject" that identifies a principal, not a set of values that describe in detail the authentication. In the ideal split, authentication has happened "satisfactorily" (whatever that means) before polkit comes into play and polkit does not need to care about who did the authentication or how it happened.

(There is probably a gap in the platform for defining the authorization policy; PAM, and especially its use in polkit, is not a good fit for network protocols.)

Libvirt isn't using DBus here, it has an alternative IPC layer, but I don't think that should exclude it from using polkit for authorization. Having to having to re-invent the wheel for authorization itself would be a disservice to administrators IMHO.

The "default" for other AF_UNIX-using IPCs is to use SO_PEERCRED or similar to get a PID, and use that as a subject. Other applications can use any other way to identify the local user - but if it is a local user that is being identified, the subject should say which local user, and not describe SASL or whatever has been used.

Having alternative subject identifications for a single connection has problematic semantics - what if the x509 cert (or local user account) is allowed but the SASL username is prohibited? I'd much prefer a "domain" model where the subject's identity is unambiguous and unique, possibly supporting several alternative ways to authenticate that identity, e.g. SASL, x.509, SCM_CREDS - but the result should be a single identity.

You already have that problem today. A client process can be associated with a UID and a GID. What if the UID is allowed, but the GID is denied?

1) Yes, we have the problem of contradictory rules and the confusion has been big enough already.

2) It's not really the same kind of problem - with UID/GID both the identity of the user and the list of groups (polkit doesn't get a GID supplied, it looks for user's groups in the NSS database) is uambiguous, only the policy might contain conflicts. With alternative subject identifications it would be possible to have a single "client" identified as several different users/principals, possibly even within the same realm/"domain".

The answer to such questions is simply up to the administrator defining the policy to decide. Via the polkit javascript rules files they can declare whether successful authorization requires both x509 cert + SASL username to be approved, or whether either one is sufficient on their own.

I'm conflicted about the concept of letting a principal use the system, and then restrict authorization for some operations depending on how they were authenticated. It makes it much more difficult to reason about the provided protection (e.g. I can login using a password only, modify ~/.bashrc, and then wait for the user to login using a smard card).

OTOH the password prompts that we have now are exactly that kind of mechanism.

Arbitrary (key valure) pairs are generally a poor way to write an API. It is structurally non-ABI-breaking, fully compatible and fully extensible, but actually it tends to only move the ABI, compatibility and extensibility concerns from the language level (where we have automated tools to help) to the semantic level (where we don't and can't have such tools).

This is pretty much irrelevant FUD.

Sure, it's separate from the question of whether to support the concept at all. It's my implementation preference, other comaintainers may well have different opinions.

[vmihalko]

In GitLab by @bugzilla-migration on Apr 29, 2013, 20:51

:speech_balloon: Tomas Mraz said:

IMHO there is missing step of mapping user credentials that are produced by authentication to uniquely identified principal (eventually with @domain part) that could be passed to polkit.

It would be nothing but a hack to pass to polkit for example raw DN from a client certificate obtained from TLS or other arbitrary name/value pairs.

See for example pam_pkcs11 how it handles mapping from the certificate DN to user names.

Eventual auxilliary data that could be useful for authorization decisions might be remote hostname and the authentication mechanism used.

[vmihalko]

In GitLab by @bugzilla-migration on Apr 29, 2013, 20:54

:speech_balloon: Miloslav Trmac said:

Stef, Tomas, others... this seems as good a place as any to try to form a plan for handling network users within polkit. (Focusing on the supported concept of user identity, not on the authorization rule mechanism.)

It needs to be consistent with the rest of the system (sssd/realmd, other components?), and I'm not quite sure what to do about application-specific concepts of "users". I'd much prefer not supporting them at all in polkit, because once they become supported, we won't be able to get rid of them.

OTOH perhaps a generic "network user: (realm, name)" concept would make sense? If we need to support users from several realms within a single computer (do we?), adding "virtual realms" to be able to express applicaton-specific identity concepts would perhaps not hurt.

[vmihalko]

In GitLab by @bugzilla-migration on Jun 18, 2013, 16:20

:speech_balloon: Stef Walter said:

(In reply to comment 5) OTOH perhaps a generic "network user: (realm, name)" concept would make sense? If we need to support users from several realms within a single computer (do we?), adding "virtual realms" to be able to express applicaton-specific identity concepts would perhaps not hurt.

The problem here is that many realms have trust relationships. So you sorta have to define the user not only by the realm, but which realm it is transiently trusted by. Such a mess. This is when the SID stuff in Windows is really quite nice :)

[vmihalko]

In GitLab by @bugzilla-migration on Jun 18, 2013, 22:40

:speech_balloon: Miloslav Trmac said:

(In reply to comment 6) (In reply to comment 5) OTOH perhaps a generic "network user: (realm, name)" concept would make sense? If we need to support users from several realms within a single computer (do we?), adding "virtual realms" to be able to express applicaton-specific identity concepts would perhaps not hurt.

The problem here is that many realms have trust relationships. So you sorta have to define the user not only by the realm, but which realm it is transiently trusted by. Such a mess. This is when the SID stuff in Windows is really quite nice :)

I'm not sure I understand - are you saying that the path matters, and that that e.g. "mitr@RedHatRealm trusted by MicrosoftRealm trusted by FreeDesktopRealm" and "mitr@RedHatRealm trusted by FreeDesktopRealm" would have different security properties?

Or just that having a "FreeDesktopRealm" configured might mean we might see users from RedHatRealm without having local information about RedHatRealm?