hyc@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays
Modified Files: dyngroup.c 1.13 -> 1.14
Log Message: Add cn=config support
I thought this was going to be replaced by dynlist, whose functionality it provides a subset. Note that in HEAD dynlist can also be instantiated under the name "dyngroup" (see obsolete names), with the same configuration syntax.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati wrote:
hyc@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays
Modified Files: dyngroup.c 1.13 -> 1.14
Log Message: Add cn=config support
I thought this was going to be replaced by dynlist, whose functionality it provides a subset. Note that in HEAD dynlist can also be instantiated under the name "dyngroup" (see obsolete names), with the same configuration syntax.
Hm, the last I remember we had agreed that dyngroup should continue to be used, since dynlist does a lot more than dyngroup needed. Did I miss something?
Howard Chu wrote:
I thought this was going to be replaced by dynlist, whose functionality it provides a subset. Note that in HEAD dynlist can also be instantiated under the name "dyngroup" (see obsolete names), with the same configuration syntax.
Hm, the last I remember we had agreed that dyngroup should continue to be used, since dynlist does a lot more than dyngroup needed. Did I miss something?
Well, at some point yes, because dynlist was doing compare in a less efficient manner, but I think this has been fixed. Otherwise, I would have probably added back-config support earlier... not a big deal, just wondering.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati wrote:
Howard Chu wrote:
I thought this was going to be replaced by dynlist, whose functionality it provides a subset. Note that in HEAD dynlist can also be instantiated under the name "dyngroup" (see obsolete names), with the same configuration syntax.
Hm, the last I remember we had agreed that dyngroup should continue to be used, since dynlist does a lot more than dyngroup needed. Did I miss something?
Well, at some point yes, because dynlist was doing compare in a less efficient manner, but I think this has been fixed. Otherwise, I would have probably added back-config support earlier... not a big deal, just wondering.
I just went back and re-read ITS#3756. If dyngroup functionality is working fine in dynlist now, then we should just cvs rm dyngroup and drop it from 2.4.
In the meantime, I need to add support for dgIdentity to something. At this point I guess that means I'll add it to dynlist.
It seems to me that we have 3 possible behaviors when the dgIdentity attribute is not present: 1) search anonymously, as suggested in the Haripriya draft 2) search as the current user, as currently implemented 3) search as "self" i.e. the group DN
I'm thinking of adding a keyword to select this behavior. This would be a single option that affects the entire overlay, not on a per-attrset basis.
Howard Chu wrote:
I just went back and re-read ITS#3756. If dyngroup functionality is working fine in dynlist now, then we should just cvs rm dyngroup and drop it from 2.4.
I'll check.
In the meantime, I need to add support for dgIdentity to something. At this point I guess that means I'll add it to dynlist.
Well, you'd kill two birds with one stone ;)
It seems to me that we have 3 possible behaviors when the dgIdentity attribute is not present: 1) search anonymously, as suggested in the Haripriya draft 2) search as the current user, as currently implemented 3) search as "self" i.e. the group DN
I'm thinking of adding a keyword to select this behavior. This would be a single option that affects the entire overlay, not on a per-attrset basis.
As I commented on ldapext@ietf.org on that draft, I think we should rather enhance that concept by providing granular access policies. For example:
a) absent dgIdentity: search with user's identity b) empty dgIdentity: search anonymously c) present dgIdentity: search with dgIdentity; but: if dgAuthz is present, check that user's identity complies with that policy (much like idassert-authzFrom, with 1.3.6.1.4.1.4203.666.2.7 OpenLDAP authz syntax.
A dgPolicy flag could determine what behavior, in case of no compliance with policy, should be taken: either (a) or (b), or none.
I don't think the original Author was fine with my remarks, so we should just take our own path, and perhaps re-define dgIdentity, to clearly depart from that (broken, IMHO) draft.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati wrote:
As I commented on ldapext@ietf.org on that draft, I think we should rather enhance that concept by providing granular access policies. For example:
a) absent dgIdentity: search with user's identity
Maintains backward compatibility, fine.
b) empty dgIdentity: search anonymously
Fine.
c) present dgIdentity: search with dgIdentity; but: if dgAuthz is present, check that user's identity complies with that policy (much like idassert-authzFrom, with 1.3.6.1.4.1.4203.666.2.7 OpenLDAP authz syntax.
A dgPolicy flag could determine what behavior, in case of no compliance with policy, should be taken: either (a) or (b), or none.
dgAuthz seems like overkill. If the user has read/search privs on the group entry, that ought to be sufficient.
I don't think the original Author was fine with my remarks, so we should just take our own path, and perhaps re-define dgIdentity, to clearly depart from that (broken, IMHO) draft.
Heh, that draft was broken in more ways than I could count.
Howard Chu wrote:
A dgPolicy flag could determine what behavior, in case of no compliance with policy, should be taken: either (a) or (b), or none.
dgAuthz seems like overkill. If the user has read/search privs on the group entry, that ought to be sufficient.
I disagree: by running an internal operation with dgIdentity, and returning the results of that operation, you'd break the security model of OpenLDAP. In fact, a dynamic group can unveal data that would otherwise be inaccessible to a user. In fact, only running the search with the user's identity guarantees the security model is not broken, but dgAuthz, at least, gives some granularity. This doesn't break either backwards compatibility nor draft-haripriya-dynamicgroup: those who want to stick with it only have to ignore dgAuthz.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati ando@sys-net.it writes:
I disagree: by running an internal operation with dgIdentity, and returning the results of that operation, you'd break the security model of OpenLDAP. In fact, a dynamic group can unveal data that would otherwise be inaccessible to a user.
This is *exactly* the behavior that Stanford needs, so please make sure that this is still possible.
Use case:
Privileges are represented in the directory via entitlements; in other words, a given user has a multivalued attribute in their directory record that contains the entitlements that user has.
Applications need to be allowed to verify, for authorization purposes, that a given user has a given entitlement, but which applications can see which entitlements needs to vary on an entitlement-by-entitlement basis (for example, some entitlements may represent data protected by FERPA, the US student information privacy act).
We want to add regular groups to the directory (rather than using compare tests against the entitlement attribute) because we can put separate ACLs on each group and then lock down access to the entitlement attribute entirely. Otherwise, we end up with a ton of substring ACLs on the entitlement attribute, which is a performance and maintenance problem.
So, that behavior of letting the dynlist or dyngroup overlay do a query that the user querying the group tree is not themselves permitted to make is exactly what we need, since we can then use the more granular access control possible on the separate group dns to implement control over entitlement visibility that's otherwise annoying to represent.
Russ Allbery wrote:
So, that behavior of letting the dynlist or dyngroup overlay do a query that the user querying the group tree is not themselves permitted to make is exactly what we need, since we can then use the more granular access control possible on the separate group dns to implement control over entitlement visibility that's otherwise annoying to represent.
The dgAuthz/dgPolicy stuff that Ando proposed doesn't preclude what you want to do. I just am not convinced yet that dgAuthz is necessary. The code I just committed for dynlist.c leaves that out for now, we can add it later if the consensus is that it's useful.
Pierangelo Masarati wrote:
Howard Chu wrote:
A dgPolicy flag could determine what behavior, in case of no compliance with policy, should be taken: either (a) or (b), or none.
dgAuthz seems like overkill. If the user has read/search privs on the group entry, that ought to be sufficient.
I disagree: by running an internal operation with dgIdentity, and returning the results of that operation, you'd break the security model of OpenLDAP. In fact, a dynamic group can unveal data that would otherwise be inaccessible to a user. In fact, only running the search with the user's identity guarantees the security model is not broken, but dgAuthz, at least, gives some granularity. This doesn't break either backwards compatibility nor draft-haripriya-dynamicgroup: those who want to stick with it only have to ignore dgAuthz.
If I create a group and give a user access to read the "member" attribute of that group, then I wanted them to be able to read that attribute, period. I don't care how the contents of that member attribute got populated.
If there is something in there that a particular user should not know about, then they simply should not have access to the entry/attribute in the first place.
As far as security goes, I think it is far more important that dyngroups behave *consistently*, such that when they are used in ACLs, they always return a predictable result. I.e., a static group yields the same information no matter how it is used or who is using it. A dyngroup should do the same (given that its constituent data remains unchanged).
Howard Chu wrote:
Pierangelo Masarati wrote:
Howard Chu wrote:
A dgPolicy flag could determine what behavior, in case of no compliance with policy, should be taken: either (a) or (b), or none.
dgAuthz seems like overkill. If the user has read/search privs on the group entry, that ought to be sufficient.
I disagree: by running an internal operation with dgIdentity, and returning the results of that operation, you'd break the security model of OpenLDAP. In fact, a dynamic group can unveal data that would otherwise be inaccessible to a user. In fact, only running the search with the user's identity guarantees the security model is not broken, but dgAuthz, at least, gives some granularity. This doesn't break either backwards compatibility nor draft-haripriya-dynamicgroup: those who want to stick with it only have to ignore dgAuthz.
If I create a group and give a user access to read the "member" attribute of that group, then I wanted them to be able to read that attribute, period. I don't care how the contents of that member attribute got populated.
If there is something in there that a particular user should not know about, then they simply should not have access to the entry/attribute in the first place.
As far as security goes, I think it is far more important that dyngroups behave *consistently*, such that when they are used in ACLs, they always return a predictable result. I.e., a static group yields the same information no matter how it is used or who is using it. A dyngroup should do the same (given that its constituent data remains unchanged).
It seems we're both talking about two different use cases.
In a typical dyngroup usage, the DNs of entries matching the URL are the only piece of information collected. For dynlist, you actually merge multiple attributes from the matching entries into the result. I agree that using a dgIdentity here may pose a risk, leaking out data that was not intended.
But again, this is presumably the reason that you created this dynamic object, assigned a dgIdentity to it, and gave read access on it. If that was not the intended purpose, then someone went to an awful lot of trouble to shoot themselves in the foot.
-
Howard Chu -
Pierangelo Masarati -
Russ Allbery