Aquisition, UserFolder and security
Hello hi I have a little problem with aquisition and security. We have a project using multiple CPS instances (for those that don't know CPS, it's a CMF based groupware/CMS) running in the same Zope instance, and being siblings of each others [1]. One of these instances is the main entry point for the portal (I'll all it the 'portal'), the others are acting as workspaces for dedicated communities (I'll call them CPMs). Each CPS instance has its own UserFolder. All users exists in the portal's UserFolder, but only exists in some CPMs UserFolders. Now the problem is that, due to acquisition, a member existing in the Portal but not in a given CPM can gain access to this CPM by faking the url - ie: going to mydomain.tld/portal/cpm instead of mydomain.tld/cpm. So we have a potential (err...) security hole here, that I would like to address ASAP. We've been thinking of using apache's rewrite rules, but since the customer will have the possibilitie to create new CPMs at will, this won't do. Idem for using subdomains, or anything implying the modification of apache conf. So we must fix the problem inside Zope itself. I searched the doc, this list's archive and the source code, and it seems that possible solutions involve playing with __bobo_traverse__ or __before_publishing_traverse__, but my (very naive) try didn't make it, so I'd really enjoy any hint and/or pointers about howtos, do's and don't, or any other resource concerning these hooks. Another thing I've been thinking of, reading BasicUserFolder's source, would be to subclass it and redefine the _isTop() method so users wouldn't been looked up for in a UserFolder placed in the context by acquisition, but I don't know enough about the whole mechanism to be sure it would'nt have unwanted side-effects and drawbacks. It's also very possible that I missed another simpler and better solution, so here again, any hint, pointer etc is *very* welcome. TIA [1] don't tell me, I know this is far from the best possible architecture, but that's the only one that we could think of that would let us meet the deadline. CPS Workspaces did not offer enough functionalities to be used for CPMs, and we need a tight integration between the Portal and CPMs. -- Bruno Desthuilliers Développeur bruno@modulix.org
Each CPS instance has its own UserFolder. All users exists in the portal's UserFolder, but only exists in some CPMs UserFolders. Now the problem is that, due to acquisition, a member existing in the Portal but not in a given CPM can gain access to this CPM by faking the url - ie: going to mydomain.tld/portal/cpm instead of mydomain.tld/cpm. So we have a potential (err...) security hole here, that I would like to address ASAP.
A normal pattern to use here would be to have one central user folder (e.g. at the root) and work with local roles in the sub-portals instead of having several user folders. jens
Jens Vagelpohl wrote:
Each CPS instance has its own UserFolder. All users exists in the portal's UserFolder, but only exists in some CPMs UserFolders. Now the problem is that, due to acquisition, a member existing in the Portal but not in a given CPM can gain access to this CPM by faking the url - ie: going to mydomain.tld/portal/cpm instead of mydomain.tld/cpm. So we have a potential (err...) security hole here, that I would like to address ASAP.
A normal pattern to use here would be to have one central user folder (e.g. at the root) and work with local roles in the sub-portals instead of having several user folders.
I know, but I don't think it will possible here (this is an euphemism). The UserFolder is a LDAPUserGroupsFolder, users data are stored in a LDAP directory, with one branch for each CPS instance, and some user data and schema varying from one branch to another. We don't have the possibility to change this (it's part of a bigger system), and we don't have the time to rewrite a custom LDAPUserFolder that could accomodate this LDAP schema (this project was already very late when we took on it and we have a *very* tight deadline - I hate this situation, but I have to deal with it...). Any robust solution, as hackish as it may be, will be just fine, as long as we deliver on time. -- Bruno Desthuilliers Développeur bruno@modulix.org
On 27 Sep 2005, at 11:17, bruno modulix wrote:
A normal pattern to use here would be to have one central user folder (e.g. at the root) and work with local roles in the sub-portals instead of having several user folders.
I know, but I don't think it will possible here (this is an euphemism). The UserFolder is a LDAPUserGroupsFolder, users data are stored in a LDAP directory, with one branch for each CPS instance, and some user data and schema varying from one branch to another. We don't have the possibility to change this (it's part of a bigger system), and we don't have the time to rewrite a custom LDAPUserFolder that could accomodate this LDAP schema (this project was already very late when we took on it and we have a *very* tight deadline - I hate this situation, but I have to deal with it...). Any robust solution, as hackish as it may be, will be just fine, as long as we deliver on time.
No idea what "LDAPUserGroupsFolder" is or what it does, but for the standard LDAPUserFolder product you would instantiate a LDAPUserSatellite object in the subportals that would be configured to look up LDAP groups in specific DIT branches and convert them to user roles. The "central" user folder would not hand out any roles itself, it's only for authentication purposes in this setup. And no, this has nothing to do with group memberships as defined by whatever group-supporting user folders you use. jens
Jens Vagelpohl wrote:
On 27 Sep 2005, at 11:17, bruno modulix wrote:
A normal pattern to use here would be to have one central user folder (e.g. at the root) and work with local roles in the sub-portals instead of having several user folders.
I know, but I don't think it will possible here (this is an euphemism). The UserFolder is a LDAPUserGroupsFolder, users data are stored in a LDAP directory, with one branch for each CPS instance, and some user data and schema varying from one branch to another. We don't have the possibility to change this (it's part of a bigger system), and we don't have the time to rewrite a custom LDAPUserFolder that could accomodate this LDAP schema (this project was already very late when we took on it and we have a *very* tight deadline - I hate this situation, but I have to deal with it...). Any robust solution, as hackish as it may be, will be just fine, as long as we deliver on time.
No idea what "LDAPUserGroupsFolder" is or what it does,
It's a modified LDAPUserFolder that supports CPS/CMF groups.
but for the standard LDAPUserFolder product you would instantiate a LDAPUserSatellite object in the subportals that would be configured to look up LDAP groups in specific DIT branches and convert them to user roles. The "central" user folder would not hand out any roles itself, it's only for authentication purposes in this setup.
Yes, but the problem here is that parts of the *users* schema and data will vary according to the CPM - it's not just a matter of roles and perms - would have been to simple :-/ Once again, I'm well aware that some architectural choices here are less than optimal, but there are strong constraints, very tight deadline, and we just don't have time to make it right - in fact barely enough time to make it work at first. God knows I don't like working that way, but still, I have to deal with it :( -- Bruno Desthuilliers Développeur bruno@modulix.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Bruno, If you're using a central LDAP for all the instances you can restrict the access from the different instances using either LDAPUserGroupsFolder or CPSUserFolder. Discrimination are done by LDAP branches (users or groups). If you can't control the LDAP and thus the way the branches are designed, for whatever reasons, then you can use CPSUserFolder and set the discrimination on the UF within each instance by setting custom CPS directories (which is what CPSUserFolder uses as proxy for authentication sources). To sum up it's a matter of configuration. We'll be glad to discuss your use case on cps-users list. Cheers, J. bruno modulix wrote:
Hello hi
I have a little problem with aquisition and security. We have a project using multiple CPS instances (for those that don't know CPS, it's a CMF based groupware/CMS) running in the same Zope instance, and being siblings of each others [1]. One of these instances is the main entry point for the portal (I'll all it the 'portal'), the others are acting as workspaces for dedicated communities (I'll call them CPMs).
Each CPS instance has its own UserFolder. All users exists in the portal's UserFolder, but only exists in some CPMs UserFolders. Now the problem is that, due to acquisition, a member existing in the Portal but not in a given CPM can gain access to this CPM by faking the url - ie: going to mydomain.tld/portal/cpm instead of mydomain.tld/cpm. So we have a potential (err...) security hole here, that I would like to address ASAP.
We've been thinking of using apache's rewrite rules, but since the customer will have the possibilitie to create new CPMs at will, this won't do. Idem for using subdomains, or anything implying the modification of apache conf.
So we must fix the problem inside Zope itself. I searched the doc, this list's archive and the source code, and it seems that possible solutions involve playing with __bobo_traverse__ or __before_publishing_traverse__, but my (very naive) try didn't make it, so I'd really enjoy any hint and/or pointers about howtos, do's and don't, or any other resource concerning these hooks.
Another thing I've been thinking of, reading BasicUserFolder's source, would be to subclass it and redefine the _isTop() method so users wouldn't been looked up for in a UserFolder placed in the context by acquisition, but I don't know enough about the whole mechanism to be sure it would'nt have unwanted side-effects and drawbacks.
It's also very possible that I missed another simpler and better solution, so here again, any hint, pointer etc is *very* welcome.
TIA
[1] don't tell me, I know this is far from the best possible architecture, but that's the only one that we could think of that would let us meet the deadline. CPS Workspaces did not offer enough functionalities to be used for CPMs, and we need a tight integration between the Portal and CPMs.
- -- Julien Anguenot | Nuxeo R&D (Paris, France) CPS Platform : http://www.cps-project.org Zope3 / ECM : http://www.z3lab.org mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDOSPWGhoG8MxZ/pIRAnL1AJ9DANrvQmDYeCqcM94uQVjW5e40wACfefAu IJ66stOnwY9kE15WkMei5MA= =tVnl -----END PGP SIGNATURE-----
Julien Anguenot wrote:
Hi Bruno,
Hi Julien,
If you're using a central LDAP for all the instances you can restrict the access from the different instances using either LDAPUserGroupsFolder or CPSUserFolder.
Discrimination are done by LDAP branches (users or groups). If you can't control the LDAP and thus the way the branches are designed, for whatever reasons, then you can use CPSUserFolder and set the discrimination on the UF within each instance by setting custom CPS directories (which is what CPSUserFolder uses as proxy for authentication sources).
To sum up it's a matter of configuration.
I'm afraid there's more to it than just a matter of configuration, cf below...
We'll be glad to discuss your use case on cps-users list.
I've spent quite some time investigating the CPSUserFolder/Metadirectories/Stackingdirectories/backingDirectories... solution, and the final word (from Olivier Grisel, cf the cps-users ml) was that some code concerning roles and groups management was not yet fully implemented, so the whole thing couldn't work without patching and merging parts of CPSDirectories - which was a definitive no-no for us. I don't know if this has been fixed in 3.3.6, but anyway, this part of our project is supposed to be already working (and mostly does, except for this security problem), and we can't afford to come back on it, as it would delay delivery by at least one week - which is also not an option. But thanks anyway... -- Bruno Desthuilliers Développeur bruno@modulix.org
Could you create a central user folder (in root) and then create an external method which queries all of the LDAP branches and returns the appropriate local roles to the central user folder when the user logs in? This way you get a central user folder and can keep all your existing LDAP branches. Just a thought. Jonathan ----- Original Message ----- From: "bruno modulix" <bruno@modulix.org> To: "Julien Anguenot" <ja@nuxeo.com> Cc: <zope@zope.org> Sent: Tuesday, September 27, 2005 7:23 AM Subject: Re: [Zope] Aquisition, UserFolder and security
Julien Anguenot wrote:
Hi Bruno,
Hi Julien,
If you're using a central LDAP for all the instances you can restrict the access from the different instances using either LDAPUserGroupsFolder or CPSUserFolder.
Discrimination are done by LDAP branches (users or groups). If you can't control the LDAP and thus the way the branches are designed, for whatever reasons, then you can use CPSUserFolder and set the discrimination on the UF within each instance by setting custom CPS directories (which is what CPSUserFolder uses as proxy for authentication sources).
To sum up it's a matter of configuration.
I'm afraid there's more to it than just a matter of configuration, cf below...
We'll be glad to discuss your use case on cps-users list.
I've spent quite some time investigating the CPSUserFolder/Metadirectories/Stackingdirectories/backingDirectories... solution, and the final word (from Olivier Grisel, cf the cps-users ml) was that some code concerning roles and groups management was not yet fully implemented, so the whole thing couldn't work without patching and merging parts of CPSDirectories - which was a definitive no-no for us.
I don't know if this has been fixed in 3.3.6, but anyway, this part of our project is supposed to be already working (and mostly does, except for this security problem), and we can't afford to come back on it, as it would delay delivery by at least one week - which is also not an option. But thanks anyway...
-- Bruno Desthuilliers Développeur bruno@modulix.org _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Jonathan wrote:
Could you create a central user folder (in root) and then create an external method which queries all of the LDAP branches and returns the appropriate local roles to the central user folder when the user logs in? This way you get a central user folder and can keep all your existing LDAP branches.
Hi Jonathan Well, I've been thinking of such a solution, but I really don't have time to rewrite the whole damn thing - also, I'm not sure CPS would support using a 'central' UserFolder, so I'd probably need to write 2 specifics UserFolders (the second one delegating to the first)
Just a thought.
Yeps, could have been a solution... -- Bruno Desthuilliers Développeur bruno@modulix.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 bruno modulix wrote:
Julien Anguenot wrote:
Hi Bruno,
Hi Julien,
If you're using a central LDAP for all the instances you can restrict the access from the different instances using either LDAPUserGroupsFolder or CPSUserFolder.
Discrimination are done by LDAP branches (users or groups). If you can't control the LDAP and thus the way the branches are designed, for whatever reasons, then you can use CPSUserFolder and set the discrimination on the UF within each instan
ce by setting custom CPS
directories (which is what CPSUserFolder uses as proxy for authentication sources).
To sum up it's a matter of configuration.
I'm afraid there's more to it than just a matter of configuration, cf below...
I confirm. For having done the intranet of the Senegal gouvernement (almost 35 CPS (one instance for each ministry) on the same Zope within a ZEO env linked on a central LDAP with differents branches for users and groups per ministry) using CPS, I have sort if an idea what you're trying todo here.
We'll be glad to discuss your use case on cps-users list.
I've spent quite some time investigating the CPSUserFolder/Metadirectories/Stackingdirectories/backingDirectories... solution, and the final word (from Olivier Grisel, cf the cps-users ml) was that some code concerning roles and groups management was not yet fully implemented, so the whole thing couldn't work without patching and merging parts of CPSDirectories - which was a definitive no-no for us.
I assume, you're talking about roles and groups compute schema fields here on directories. This is TALES expression linking the directories. The code can be wherever you wanna, even within the TALES expression if you feel like... That's probably, what Olivier tried to say. Still I didn't follow the discussion at this time. Let me add that CPSUserFolder works and is in production for a while now in several projects. So be sure it's stable.
I don't know if this has been fixed in 3.3.6, but anyway, this part of our project is supposed to be already working (and mostly does, except for this security problem), and we can't afford to come back on it, as it would delay delivery by at least one week - which is also not an option. But thanks anyway...
Then, you might have a design flaw... You didn' reply to my question at the first place : are you controling the LDAP (rw) ? Are the schemas describing your users differents in between the CPS instances ? etc... CPSUserFolder has been designed to tackle such a use case. (Not only this use case but this one has been a reason of the existence of this product.) Of course, looking for a hack to deliver your project can always be solution ;) Cheers, J. - -- Julien Anguenot | Nuxeo R&D (Paris, France) CPS Platform : http://www.cps-project.org Zope3 / ECM : http://www.z3lab.org mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDOUcwGhoG8MxZ/pIRAomtAJ4lEnUDUZpLIkcjwgSTdShb/TTcXwCggTsy EcWsb2Z2oSOgHxsdhgnwNjc= =9Hzy -----END PGP SIGNATURE-----
Julien Anguenot wrote:
bruno modulix wrote:
Julien Anguenot wrote:
(snip)
To sum up it's a matter of configuration.
I'm afraid there's more to it than just a matter of configuration, cf below...
I confirm. For having done the intranet of the Senegal gouvernement (almost 35 CPS (one instance for each ministry) on the same Zope within a ZEO env linked on a central LDAP with differents branches for users and groups per ministry) using CPS, I have sort if an idea what you're trying todo here.
I've spent quite some time investigating the CPSUserFolder/Metadirectories/Stackingdirectories/backingDirectories... solution, and the final word (from Olivier Grisel, cf the cps-users ml) was that some code concerning roles and groups management was not yet fully implemented, so the whole thing couldn't work without patching and merging parts of CPSDirectories - which was a definitive no-no for us.
I assume, you're talking about roles and groups compute schema fields here on directories. This is TALES expression linking the directories. The code can be wherever you wanna, even within the TALES expression if you feel like...
That's probably, what Olivier tried to say. Still I didn't follow the discussion at this time.
Too bad :( You'll find it on the cps-users list. I'm not a CPS expert[1] - and not even a Zope expert - but from what I saw, it seemed to imply more than only TALES expressions... [1] given the change pace and resulting lack of documentation, I guess only you Nuxeo guys have a good understanding of the whole product...
Let me add that CPSUserFolder works and is in production for a while now in several projects. So be sure it's stable.
I don't doubt it works fine. I just didn't managed to make the whole thing work, and couldn't afford to spend more time on it.
I don't know if this has been fixed in 3.3.6, but anyway, this part of our project is supposed to be already working (and mostly does, except for this security problem), and we can't afford to come back on it, as it would delay delivery by at least one week - which is also not an option. But thanks anyway...
Then, you might have a design flaw...
Probably. Certainly. But we'll have to live with it for at least this and next iteration - our customer needs a working solution for yesterday, and we have pretty good reasons to do whatever we can to deliver yesterday.
You didn' reply to my question at the first place : are you controling the LDAP (rw) ?
Actually, no, r only. As I answered to Jens, it's part of a bigger system, and we have very few freedom here. This will probably change in the future, but we must first deal with the existing situation.
Are the schemas describing your users differents in between the CPS instances ?
Yes.
etc...
CPSUserFolder has been designed to tackle such a use case. (Not only this use case but this one has been a reason of the existence of this product.)
I know, that's why my first try was to use the CPSUserFolder + metadirectories + etc solution. Now from what I saw (I may have missed some points, but...), we concluded that using LDAPUserGroupsFolder, at least for the first rounds, would be much more manageable - we (well... I) only forgot that aquisition could come in the way :(
Of course, looking for a hack to deliver your project can always be solution ;)
I'm afraid it's the only short-term solution we have. -- Bruno Desthuilliers Développeur bruno@modulix.org
If you are really behind the 8-ball here is a really ugly work around that may buy you some time to fix it properly: after you authenticate a user, use a dtml method (eg. 'method1') to invoke the target method (eg. <dtml-var "/.../.../somemethod">) in 'somemethod' check to make sure that it was invoked by 'method1' (use a REQUEST var such as SCRIPT_URI or PATH_TRANSLATED). If you came from method1 then let the user proceed, if not do a RESPONSE.redirect somewhere else (eg home page - i wouldn't display an error message, you don't want to help the hackers). This is a reaallly bad hack, and is not very secure, but it may buy you some time to fix the problem properly. Good Luck! Jonathan ----- Original Message ----- From: "bruno modulix" <bruno@modulix.org> To: "Julien Anguenot" <ja@nuxeo.com> Cc: <zope@zope.org> Sent: Tuesday, September 27, 2005 10:31 AM Subject: Re: [Zope] Aquisition, UserFolder and security
Julien Anguenot wrote:
bruno modulix wrote:
Julien Anguenot wrote:
(snip)
To sum up it's a matter of configuration.
I'm afraid there's more to it than just a matter of configuration, cf below...
I confirm. For having done the intranet of the Senegal gouvernement (almost 35 CPS (one instance for each ministry) on the same Zope within a ZEO env linked on a central LDAP with differents branches for users and groups per ministry) using CPS, I have sort if an idea what you're trying todo here.
I've spent quite some time investigating the CPSUserFolder/Metadirectories/Stackingdirectories/backingDirectories... solution, and the final word (from Olivier Grisel, cf the cps-users ml) was that some code concerning roles and groups management was not yet fully implemented, so the whole thing couldn't work without patching and merging parts of CPSDirectories - which was a definitive no-no for us.
I assume, you're talking about roles and groups compute schema fields here on directories. This is TALES expression linking the directories. The code can be wherever you wanna, even within the TALES expression if you feel like...
That's probably, what Olivier tried to say. Still I didn't follow the discussion at this time.
Too bad :(
You'll find it on the cps-users list. I'm not a CPS expert[1] - and not even a Zope expert - but from what I saw, it seemed to imply more than only TALES expressions...
[1] given the change pace and resulting lack of documentation, I guess only you Nuxeo guys have a good understanding of the whole product...
Let me add that CPSUserFolder works and is in production for a while now in several projects. So be sure it's stable.
I don't doubt it works fine. I just didn't managed to make the whole thing work, and couldn't afford to spend more time on it.
I don't know if this has been fixed in 3.3.6, but anyway, this part of our project is supposed to be already working (and mostly does, except for this security problem), and we can't afford to come back on it, as it would delay delivery by at least one week - which is also not an option. But thanks anyway...
Then, you might have a design flaw...
Probably. Certainly. But we'll have to live with it for at least this and next iteration - our customer needs a working solution for yesterday, and we have pretty good reasons to do whatever we can to deliver yesterday.
You didn' reply to my question at the first place : are you controling the LDAP (rw) ?
Actually, no, r only. As I answered to Jens, it's part of a bigger system, and we have very few freedom here. This will probably change in the future, but we must first deal with the existing situation.
Are the schemas describing your users differents in between the CPS instances ?
Yes.
etc...
CPSUserFolder has been designed to tackle such a use case. (Not only this use case but this one has been a reason of the existence of this product.)
I know, that's why my first try was to use the CPSUserFolder + metadirectories + etc solution.
Now from what I saw (I may have missed some points, but...), we concluded that using LDAPUserGroupsFolder, at least for the first rounds, would be much more manageable - we (well... I) only forgot that aquisition could come in the way :(
Of course, looking for a hack to deliver your project can always be solution ;)
I'm afraid it's the only short-term solution we have.
-- Bruno Desthuilliers Développeur bruno@modulix.org _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 bruno modulix wrote:
You'll find it on the cps-users list. I'm not a CPS expert[1] - and not even a Zope expert - but from what I saw, it seemed to imply more than only TALES expressions...
[1] given the change pace and resulting lack of documentation, I guess only you Nuxeo guys have a good understanding of the whole product...
CPS is an open process so contributions such as documentation, patches, codes, ideas etc... is always warmly welcome.
Then, you might have a design flaw...
Probably. Certainly. But we'll have to live with it for at least this and next iteration - our customer needs a working solution for yesterday, and we have pretty good reasons to do whatever we can to deliver yesterday.
I understand.
You didn' reply to my question at the first place : are you controling the LDAP (rw) ?
Actually, no, r only. As I answered to Jens, it's part of a bigger system, and we have very few freedom here. This will probably change in the future, but we must first deal with the existing situation.
Are the schemas describing your users differents in between the CPS instances ?
Yes.
Argh..., it really would have been a job for CPSUserFolder... J. - -- Julien Anguenot | Nuxeo R&D (Paris, France) CPS Platform : http://www.cps-project.org Zope3 / ECM : http://www.z3lab.org mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDOWQ6GhoG8MxZ/pIRAhfuAJ9QIcUEnYByf+lFhJ7kDQwzl+2shQCfUL29 9pko5wDmumsH/abUt/+rkiE= =9xHS -----END PGP SIGNATURE-----
Julien Anguenot wrote:
bruno modulix wrote:
You'll find it on the cps-users list. I'm not a CPS expert[1] - and not even a Zope expert - but from what I saw, it seemed to imply more than only TALES expressions...
[1] given the change pace and resulting lack of documentation, I guess only you Nuxeo guys have a good understanding of the whole product...
CPS is an open process so contributions such as documentation, patches, codes, ideas etc... is always warmly welcome.
I don't doubt it, but you'll agree that to document something, one has first to know how it works !-) Don't take me wrong, I'm not complaining about the lack of documentation - I know what is takes to document a project, and the fast changes surely don't help here. It's just a fact that CPS documentation is sparse and usually somewhat out-of-date, so it's "use the code, Luke". Actually, my very modest contributions are restricted to a couple of tickets and work-around in Trac. More may come if and when I'll find time for it.
Then, you might have a design flaw...
Probably. Certainly. But we'll have to live with it for at least this and next iteration - our customer needs a working solution for yesterday, and we have pretty good reasons to do whatever we can to deliver yesterday.
I understand.
You didn' reply to my question at the first place : are you controling the LDAP (rw) ?
Actually, no, r only.
(snip)
Are the schemas describing your users differents in between the CPS instances ?
Yes.
Argh..., it really would have been a job for CPSUserFolder...
Yes, I know. And I would be sorry to conclude that I misunderstood what it took to make it work and gave up when I was almost done :-/ But I still have to find a way to handle the current situation... As I said at first, my guesses are either hacking the _isTop() method of LDAPUserGroupsFolder or finding some good hints/doc on using traversal hooks. If you can be of any help here, please be sure you'll gain "ma reconnaissance éternelle"... -- Bruno Desthuilliers Développeur bruno@modulix.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 bruno modulix wrote:
Julien Anguenot wrote:
bruno modulix wrote:
You'll find it on the cps-users list. I'm not a CPS expert[1] - and not even a Zope expert - but from what I saw, it seemed to imply more than only TALES expressions...
[1] given the change pace and resulting lack of documentation, I guess only you Nuxeo guys have a good understanding of the whole product...
CPS is an open process so contributions such as documentation, patches, codes, ideas etc... is always warmly welcome.
I don't doubt it, but you'll agree that to document something, one has first to know how it works !-)
Don't take me wrong, I'm not complaining about the lack of documentation - I know what is takes to document a project, and the fast changes surely don't help here. It's just a fact that CPS documentation is sparse and usually somewhat out-of-date, so it's "use the code, Luke".
Actually, my very modest contributions are restricted to a couple of tickets and work-around in Trac. More may come if and when I'll find time for it.
Then, you might have a design flaw...
Probably. Certainly. But we'll have to live with it for at least this and next iteration - our customer needs a working solution for yesterday, and we have pretty good reasons to do whatever we can to deliver yesterday.
I understand.
You didn' reply to my question at the first place : are you controling the LDAP (rw) ?
Actually, no, r only.
(snip)
Are the schemas describing your users differents in between the CPS instances ?
Yes.
Argh..., it really would have been a job for CPSUserFolder...
Yes, I know. And I would be sorry to conclude that I misunderstood what it took to make it work and gave up when I was almost done :-/
But I still have to find a way to handle the current situation... As I said at first, my guesses are either hacking the _isTop() method of LDAPUserGroupsFolder or finding some good hints/doc on using traversal hooks. If you can be of any help here, please be sure you'll gain "ma reconnaissance éternelle"...
As I said you should move the discussion on cps-users (and even cps-users-fr since you're French speaking) and expose your use case in details so that we can help you. zope@zope.org is not the most accurate place for this I guess. Cheers, J. - -- Julien Anguenot | Nuxeo R&D (Paris, France) CPS Platform : http://www.cps-project.org Zope3 / ECM : http://www.z3lab.org mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDOWtuGhoG8MxZ/pIRAqhTAJ9V6L2B8ayepDGdEsHFB027/mE79wCaAl89 Vs1+yRlXiCtn4WlBQMtB1w4= =D5IH -----END PGP SIGNATURE-----
bruno modulix wrote: (snip)
Each CPS instance has its own UserFolder. All users exists in the portal's UserFolder, but only exists in some CPMs UserFolders. Now the problem is that, due to acquisition, a member existing in the Portal but not in a given CPM can gain access to this CPM by faking the url - ie: going to mydomain.tld/portal/cpm instead of mydomain.tld/cpm. So we have a potential (err...) security hole here, that I would like to address ASAP.
(snip)
Another thing I've been thinking of, reading BasicUserFolder's source, would be to subclass it and redefine the _isTop() method so users wouldn't been looked up for in a UserFolder placed in the context by acquisition, but I don't know enough about the whole mechanism to be sure it would'nt have unwanted side-effects and drawbacks.
Ok, I've tried a Q&D hack here, redifining userFolder's _isTop() to always return True, and it seems to do the job. But if someone is aware of any drawback of this hack (apart from the fact that there's no more way to authenticate again a 'higher' userFolder...), I'd be interested...
It's also very possible that I missed another simpler and better solution, so here again, any hint, pointer etc is *very* welcome.
This still holds !-) And thanks to the Three Jeez (Jens, Julien and Jonathan) for having taking time to try to help me. -- Bruno Desthuilliers Développeur bruno@modulix.org
bruno modulix wrote at 2005-9-27 11:34 +0200:
I have a little problem with aquisition and security. We have a project using multiple CPS instances (for those that don't know CPS, it's a CMF based groupware/CMS) running in the same Zope instance, and being siblings of each others [1]. One of these instances is the main entry point for the portal (I'll all it the 'portal'), the others are acting as workspaces for dedicated communities (I'll call them CPMs).
Each CPS instance has its own UserFolder. All users exists in the portal's UserFolder, but only exists in some CPMs UserFolders. Now the problem is that, due to acquisition, a member existing in the Portal but not in a given CPM can gain access to this CPM by faking the url - ie: going to mydomain.tld/portal/cpm instead of mydomain.tld/cpm. So we have a potential (err...) security hole here, that I would like to address ASAP.
Sounds like a permission to role mapping flaw... Apparently, roles controlled by the "Portal" UserFolder (e.g. "Authenticated") are allowed to do things in your CPM that you only be allowed by roles controlled by their UserFolder. You may be able to fix this by making the roles controlled by the "Portal" and the "CPM" level disjoint. "Authenticated" cannot be made disjoint -- but you may not use it inside your CPMs. -- Dieter
Dieter Maurer wrote: Hi Dieter
bruno modulix wrote at 2005-9-27 11:34 +0200:
I have a little problem with aquisition and security. We have a project using multiple CPS instances (for those that don't know CPS, it's a CMF based groupware/CMS) running in the same Zope instance, and being siblings of each others [1]. One of these instances is the main entry point for the portal (I'll all it the 'portal'), the others are acting as workspaces for dedicated communities (I'll call them CPMs).
Each CPS instance has its own UserFolder. All users exists in the portal's UserFolder, but only exists in some CPMs UserFolders. Now the problem is that, due to acquisition, a member existing in the Portal but not in a given CPM can gain access to this CPM by faking the url - ie: going to mydomain.tld/portal/cpm instead of mydomain.tld/cpm. So we have a potential (err...) security hole here, that I would like to address ASAP.
Sounds like a permission to role mapping flaw...
Apparently, roles controlled by the "Portal" UserFolder (e.g. "Authenticated") are allowed to do things in your CPM that you only be allowed by roles controlled by their UserFolder.
You may be able to fix this by making the roles controlled by the "Portal" and the "CPM" level disjoint.
"Authenticated" cannot be made disjoint -- but you may not use it inside your CPMs.
The problem here is that CPS (the portal and all CPMs are CPS instances) uses predefined roles, on which the various workflows relies, so that would mean renaming all roles - differently - on each CPM, and modifying the workflows too. Given that the customer is going to create new CPMs "at will", I'm afraid this solution is somewhat unpractical... -- Bruno Desthuilliers Développeur bruno@modulix.org
+-------[ bruno modulix ]---------------------- | Dieter Maurer wrote: | | Hi Dieter | | > bruno modulix wrote at 2005-9-27 11:34 +0200: | > | >>I have a little problem with aquisition and security. We have a project | >>using multiple CPS instances (for those that don't know CPS, it's a CMF | >>based groupware/CMS) running in the same Zope instance, and being | >>siblings of each others [1]. One of these instances is the main entry | >>point for the portal (I'll all it the 'portal'), the others are acting | >>as workspaces for dedicated communities (I'll call them CPMs). | >> | >>Each CPS instance has its own UserFolder. All users exists in the | >>portal's UserFolder, but only exists in some CPMs UserFolders. Now the | >>problem is that, due to acquisition, a member existing in the Portal but | >>not in a given CPM can gain access to this CPM by faking the url - ie: | >>going to mydomain.tld/portal/cpm instead of mydomain.tld/cpm. So we have | >>a potential (err...) security hole here, that I would like to address ASAP. | > | > | > Sounds like a permission to role mapping flaw... | > | > Apparently, roles controlled by the "Portal" UserFolder (e.g. | > "Authenticated") are allowed to do things in your CPM that | > you only be allowed by roles controlled by their UserFolder. | > | > You may be able to fix this by making the roles controlled | > by the "Portal" and the "CPM" level disjoint. | > | > "Authenticated" cannot be made disjoint -- but you may not use | > it inside your CPMs. | | The problem here is that CPS (the portal and all CPMs are CPS instances) | uses predefined roles, on which the various workflows relies, so that | would mean renaming all roles - differently - on each CPM, and modifying | the workflows too. Given that the customer is going to create new CPMs | "at will", I'm afraid this solution is somewhat unpractical... And turning off "Acquire" roles on the security tab of the folders you don't want to have acquired doesn't work? -- Andrew Milton akm@theinternet.com.au
Andrew Milton wrote: (snip)
And turning off "Acquire" roles on the security tab of the folders you don't want to have acquired doesn't work?
This would probably be the cleanest solution here, and - shame on me - I didn't even think of it. Now the problem is that CPS has a very complex permission/roles/groups scheme, and I wouldn't want to mess with it. Anyway, I found a working hack^Msolution that do the trick and seems not to have too much drawbacks for now - mostly, overriding the _isTop() method and looking for another CPS instance in aq_chain, if so return True, which prevent looking further. Since there won't be another CPS instance in the aq_chain when managing the application from the ZMI, it should be ok (and AFAICT it works just fine). -- Bruno Desthuilliers Développeur bruno@modulix.org
bruno modulix wrote at 2005-9-28 10:02 +0200:
Dieter Maurer wrote: ...
Sounds like a permission to role mapping flaw...
Apparently, roles controlled by the "Portal" UserFolder (e.g. "Authenticated") are allowed to do things in your CPM that you only be allowed by roles controlled by their UserFolder.
You may be able to fix this by making the roles controlled by the "Portal" and the "CPM" level disjoint.
"Authenticated" cannot be made disjoint -- but you may not use it inside your CPMs.
The problem here is that CPS (the portal and all CPMs are CPS instances) uses predefined roles, on which the various workflows relies, so that would mean renaming all roles - differently - on each CPM, and modifying the workflows too.
I think that is would only be necessary that the roles are disjoint between "Portal" and "CPM". All "CPM"s can use the same roles.
Given that the customer is going to create new CPMs "at will", I'm afraid this solution is somewhat unpractical...
Maybe, this changes when you need to touch only the "Portal" roles? -- Dieter
Dieter Maurer wrote:
bruno modulix wrote at 2005-9-28 10:02 +0200:
Dieter Maurer wrote: ...
Sounds like a permission to role mapping flaw...
Apparently, roles controlled by the "Portal" UserFolder (e.g. "Authenticated") are allowed to do things in your CPM that you only be allowed by roles controlled by their UserFolder.
You may be able to fix this by making the roles controlled by the "Portal" and the "CPM" level disjoint.
"Authenticated" cannot be made disjoint -- but you may not use it inside your CPMs.
The problem here is that CPS (the portal and all CPMs are CPS instances) uses predefined roles, on which the various workflows relies, so that would mean renaming all roles - differently - on each CPM, and modifying the workflows too.
I think that is would only be necessary that the roles are disjoint between "Portal" and "CPM". All "CPM"s can use the same roles.
Nope. Some users may have different roles from CPM to CPM.
Given that the customer is going to create new CPMs "at will", I'm afraid this solution is somewhat unpractical...
Maybe, this changes when you need to touch only the "Portal" roles?
I don't want to mess with CPS predifined roles. But thanks anyway. -- Bruno Desthuilliers Développeur bruno@modulix.org
bruno modulix wrote at 2005-9-29 13:20 +0200:
...
The problem here is that CPS (the portal and all CPMs are CPS instances) uses predefined roles, on which the various workflows relies, so that would mean renaming all roles - differently - on each CPM, and modifying the workflows too.
I think that is would only be necessary that the roles are disjoint between "Portal" and "CPM". All "CPM"s can use the same roles.
Nope. Some users may have different roles from CPM to CPM.
I did not say that the "user to role" mapping should (or even must) be identical in all CPMs but that the *set* of roles *might* be identical in all CPMs -- or to say it differently: that you are not forced to use disjoint role sets for any pair of CPMs. Hopefully, you see the difference... -- Dieter
Dieter Maurer wrote:
bruno modulix wrote at 2005-9-29 13:20 +0200:
...
The problem here is that CPS (the portal and all CPMs are CPS instances) uses predefined roles, on which the various workflows relies, so that would mean renaming all roles - differently - on each CPM, and modifying the workflows too.
I think that is would only be necessary that the roles are disjoint between "Portal" and "CPM". All "CPM"s can use the same roles.
Nope. Some users may have different roles from CPM to CPM.
I did not say that the "user to role" mapping should (or even must) be identical in all CPMs but that the *set* of roles *might* be identical in all CPMs -- or to say it differently: that you are not forced to use disjoint role sets for any pair of CPMs.
Hopefully, you see the difference...
Dieter, I didn't misunderstood your proposed solution. But some users exist in different CPMs with different roles in each CPM. So - unless I'm totally at lost with how Zope's security works - if User1 has role RoleWithMuchPrivileges in Cpm1 and role RoleWithFewPrivileges in Cpm2, he could gain RoleWithMuchPrivileges in Cpm2 just by using faked url cpm1/cpm2/whatever_he_should_not_access_here. Worse, anyone existing in any CPM could gain access to any other CPM just by faking url. See, it's not only a 'portal roles' vs 'CPMs roles' problem, it's a 'siblings CPS instances in the same Zope container with a same domain name' problem. Playing with roles and permissions aquisition settings and whatever is not the solution here IMHO. Detecting and correcting 'faked' urls would be simpler and better - and that's somehow the solution I applyed - even if in a somewhat hackish way. BTW I'm still looking for a "hands on" doc on traversal hooks, if there's such a thing... -- Bruno Desthuilliers Développeur bruno@modulix.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 bruno modulix wrote:
Dieter, I didn't misunderstood your proposed solution. But some users exist in different CPMs with different roles in each CPM. So - unless I'm totally at lost with how Zope's security works - if User1 has role RoleWithMuchPrivileges in Cpm1 and role RoleWithFewPrivileges in Cpm2, he could gain RoleWithMuchPrivileges in Cpm2 just by using faked url cpm1/cpm2/whatever_he_should_not_access_here. Worse, anyone existing in any CPM could gain access to any other CPM just by faking url.
The Zope security machinery goes out of its way to prevent such an exploit: essentially, it considers only "containment" acquisition when evaluating roles, etc. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDPTZA+gerLs4ltQ4RApDKAKC60CDyD0rIdCN/CC8dMmPbreeAKACZAUB3 cX01OZuxOaIL1hNnXS1NxrI= =VlQo -----END PGP SIGNATURE-----
Tres Seaver wrote:
bruno modulix wrote:
Dieter, I didn't misunderstood your proposed solution. But some users exist in different CPMs with different roles in each CPM. So - unless I'm totally at lost with how Zope's security works - if User1 has role RoleWithMuchPrivileges in Cpm1 and role RoleWithFewPrivileges in Cpm2, he could gain RoleWithMuchPrivileges in Cpm2 just by using faked url cpm1/cpm2/whatever_he_should_not_access_here. Worse, anyone existing in any CPM could gain access to any other CPM just by faking url.
The Zope security machinery goes out of its way to prevent such an exploit:
Which one ? I have the case where authentication happens in the context, not containment, ie given two sibling folders fa and fb, each with it's own acl_user, if UserA exists in fa['acl_users'] and not in fb['acl_users'], then UserA is still authenticated in fb when accessing it thru fa/fb (while he is not when accessing fb directly).
essentially, it considers only "containment" acquisition when evaluating roles, etc.
I wasn't very sure about this. If I understand correctly, this means that authentication can come from an acl_user aquired by context (this is what I've experimented), but that roles/permission lookup will only happens in the containment hierarchy ? -- Bruno Desthuilliers Développeur bruno@modulix.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 bruno modulix wrote:
Dieter, I didn't misunderstood your proposed solution. But some users exist in different CPMs with different roles in each CPM. So - unless I'm totally at lost with how Zope's security works - if User1 has role RoleWithMuchPrivileges in Cpm1 and role RoleWithFewPrivileges in Cpm2, he could gain RoleWithMuchPrivileges in Cpm2 just by using faked url cpm1/cpm2/whatever_he_should_not_access_here. Worse, anyone existing in any CPM could gain access to any other CPM just by faking url.
The Zope2 security machinery explicitly prevents such abuse by considering only "containment" acquisition when evaluating local roles, acquired permission maps, etc. It also insists that the user being considered exist "in context of" the object being validated. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDPTcq+gerLs4ltQ4RAuJKAJ0Y6z6iNRMuH7AgjVvF3rOI5FTFkQCfV5SU zV03BmP/HeQa2KHVFhhHdrA= =JmJp -----END PGP SIGNATURE-----
bruno modulix wrote:
Dieter, I didn't misunderstood your proposed solution. But some users exist in different CPMs with different roles in each CPM. So - unless I'm totally at lost with how Zope's security works - if User1 has role RoleWithMuchPrivileges in Cpm1 and role RoleWithFewPrivileges in Cpm2, he could gain RoleWithMuchPrivileges in Cpm2 just by using faked url cpm1/cpm2/whatever_he_should_not_access_here. Worse, anyone existing in any CPM could gain access to any other CPM just by faking url.
As Tres mentionned, that should not be possible, as it's contrary to the Zope Security Policy. Can you reproduce it within a blank CPS instance using standard CPS products? If yes, could you explain the steps to reproduce it, and the versions of CPS, CMF, Zope and python you use? Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
I was looking for a ldap browser for zope/plone and I found this product LDAP Directory Manager but it has no releases since 2004. Somebody know if this product is stable with the latest versions of zope/plone? Or there is another product to browse ldap for zope/plone? Any help would be much appreciated! Marcos Iuato
Florent Guillaume wrote:
bruno modulix wrote:
Dieter, I didn't misunderstood your proposed solution. But some users exist in different CPMs with different roles in each CPM. So - unless I'm totally at lost with how Zope's security works - if User1 has role RoleWithMuchPrivileges in Cpm1 and role RoleWithFewPrivileges in Cpm2, he could gain RoleWithMuchPrivileges in Cpm2 just by using faked url cpm1/cpm2/whatever_he_should_not_access_here. Worse, anyone existing in any CPM could gain access to any other CPM just by faking url.
As Tres mentionned, that should not be possible, as it's contrary to the Zope Security Policy.
As I mentionned, I may *also* be completely at lost with the inners of Zope's escurity policy :-/
Can you reproduce it within a blank CPS instance using standard CPS products? If yes, could you explain the steps to reproduce it, and the versions of CPS, CMF, Zope and python you use?
What I observed is that, given 2 siblings CPS (cpsA and cpsB) instances with LDAPUserGroupsFolder, a user existing only in cpsA, once authenticated in cpsA, is still viewed as authenticated when accessing cpsB thru the cpsA/cpsb url. I don't have much time right now to investigate further, but I'll do ASAP and let you know if I find anything strange. -- Bruno Desthuilliers Développeur bruno@modulix.org
bruno modulix wrote at 2005-9-30 09:38 +0200:
... Dieter, I didn't misunderstood your proposed solution. But some users exist in different CPMs with different roles in each CPM. So - unless I'm totally at lost with how Zope's security works - if User1 has role RoleWithMuchPrivileges in Cpm1 and role RoleWithFewPrivileges in Cpm2, he could gain RoleWithMuchPrivileges in Cpm2 just by using faked url cpm1/cpm2/whatever_he_should_not_access_here. Worse, anyone existing in any CPM could gain access to any other CPM just by faking url.
In fact, this should not be the case: The user comes from some user folder and gets the roles associated with it in that user folder. Due to acquistion fakes the authorizing user folder may not be the one adequate for the object being accessed. However, part of the access check is the verification that the object is governed by the authorizing user folder (this means the object must be at or below the folder containing the authorizing user folder). If this verification fails and the access was protected in the first place, then access will be denied. Thus, acquisition fakes should not be able to give a user higher priviledges on an object than it would get by a user folder which governs the object. Summary: Only your "Portal" user folder can give "CPM" priviledges higher than the one granted by the "CPM" user folder. User folders of other "CPM"s cannot do this. -- Dieter
participants (9)
-
Andrew Milton -
bruno modulix -
Dieter Maurer -
Florent Guillaume -
Jens Vagelpohl -
Jonathan -
Julien Anguenot -
Marcos Iuato -
Tres Seaver