[Zope3-dev] Certification: Supporting Residual Information Protection in Zope 3
Hi, within the certification we once created a list (drawn from the CC catalogue) of functionality we want to support. One of those is called Residual Information Protection (RIP) The meaning of RIP is that when you delete security attributes (roles, users, groups, permission grants/denials) you want to make sure that the overall consistency of your security attributes is not affected. Example: Bob is a user of your site with the login name bob. He was granted permissions all over the place, for example in folder /asdf he has the permission perm.ModifyObjects. Bob doesn't want to work with you anymore and tells you so. You delete the user account bob from the system. 2 years later. Another Bob arrives and you assign him the same username. Suddenly he has all the permissions that the original bob had. This is a simple example of what can happen when you only partially delete security attributes. And it is a known problem with todays Zope 2 security. Two questions arise for me now, as I face implementing the effective removal of residual data: - Does anybody know/understand whether this will heavily collide with undoing transactions or not? - Is there an efficient way on the application-level in Zope 3 to iterate over objects out of the database? (There is something in the ZODB IIRC that can support iterating over objects of the same class) Otherwise this function is likely to become a performance killer, as I'd have to go all over the place to remove stuff. Cheers, Christian -- gocept gmbh co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Certification: Supporting Residual Information Protection in Zope 3
Christian Theune wrote: Hi, within the certification we once created a list (drawn from the CC catalogue) of functionality we want to support. One of those is called Residual Information Protection (RIP) The meaning of RIP is that when you delete security attributes (roles, users, groups, permission grants/denials) you want to make sure that the overall consistency of your security attributes is not affected. Example: Bob is a user of your site with the login name bob. He was granted permissions all over the place, for example in folder /asdf he has the permission perm.ModifyObjects. Bob doesn't want to work with you anymore and tells you so. You delete the user account bob from the system. 2 years later. Another Bob arrives and you assign him the same username. Suddenly he has all the permissions that the original bob had. This is a simple example of what can happen when you only partially delete security attributes. And it is a known problem with todays Zope 2 security. This is only a problem if username === user id. In both Zope 2 and Zope 3, these are distinct, although this isn't widely recognized or leveraged in Zope 2. I don't think it is necessary to remove all grants to an old user *id* as long as ids are never reused. I'd say it might even be useful to keep the old grants, at least for some period, for auditing purposed. If we *do* need to be able to remove all grants for a deleted user when we remove a user, then we need to provide an authorization system that makes this possible. Two questions arise for me now, as I face implementing the effective removal of residual data: - Does anybody know/understand whether this will heavily collide with undoing transactions or not? It would. The Undo feature should not be included in the CC certified version, or, perhaps undo should only be exposed to adminstrators as a break glass sort of feature. The reason is that, for current versions of ZODB, undo cannot maintain transactional integrity. - Is there an efficient way on the application-level in Zope 3 to iterate over objects out of the database? (There is something in the ZODB IIRC that can support iterating over objects of the same class) Otherwise this function is likely to become a performance killer, as I'd have to go all over the place to remove stuff. By definition, there is no efficient way to iterate over all objects in a database, any database, unless the database is small. If we need to be able to do this, we should design support into the authorization system that we certify. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Certification: Supporting Residual Information Protection in Zope 3
Hi, Am Freitag, den 16.12.2005, 07:16 -0500 schrieb Jim Fulton: This is only a problem if username === user id. In both Zope 2 and Zope 3, these are distinct, although this isn't widely recognized or leveraged in Zope 2. I don't think it is necessary to remove all grants to an old user *id* as long as ids are never reused. I'd say it might even be useful to keep the old grants, at least for some period, for auditing purposed. If we *do* need to be able to remove all grants for a deleted user when we remove a user, then we need to provide an authorization system that makes this possible. I think if we can guarantee never to reuse a user id, provide a tool for doing RIP and we do not provide undo we are fine. By definition, there is no efficient way to iterate over all objects in a database, any database, unless the database is small. If we need to be able to do this, we should design support into the authorization system that we certify. Agreed. This would mean that the authorization system (which is policy dependant if I understand it correctly) will have to maintain data structures that allow efficient handling for those tasks. Right? Christian -- gocept gmbh co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Certification: Supporting Residual Information Protection in Zope 3
Jim Fulton wrote: ... If we need to be able to do this, we should design support into the authorization system that we certify. I'll note that this implies that the grants are stored centrally. There are a number of reasons why this might be beneficial. It's interesting to note that on Unix systems, it is not too terribly expensive (though not cheap) to change security information on a large tree. (I'd guess the same is true on Windows, probably for similar reasons.) This is because the information is stored in inodes, rather than in the files themselves. The actual files don't need to be open and read. In our current annotation-based approach, we have to load an object to get it's grant annotation. A pet project of mine that I'm dying to work on, but fear I won't have time for, is to add optional support for managing security information in ZODB. A storage that supports object security would maintain extra information, accessable as additional persistent objects, that maintain lists of principal grants for each object. A grant for a principal for an object would be a triple of boolean values for read, write, and ownership, where you would need the ownership to change the grants. Of course, the storage would use this information to mediate access. The main goal of this would be to make ZEO a much more viable protocol for client-server applications. I also think that the flexible permission scheme I introduced to Zope was a huge mistake. A security system that people don't understand is insecure. A corrolary of this is that complex security systems are not secure. I wish I knew more (had time to read literature) about usable security systems. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Certification: Supporting Residual Information Protection in Zope 3
Hi, Am Freitag, den 16.12.2005, 07:49 -0500 schrieb Jim Fulton: Christian Theune wrote: I think if we can guarantee never to reuse a user id, provide a tool for doing RIP and we do not provide undo we are fine. Only if we manage the user ids. We often get principal ids from outside sources. In fact, we usually do this in production. In the case when we're using an external principal soure, we also don't autmatically know when the principal is removed. Also, current principal-management facilities in Zope 3 allow managers to pick ids. We probably would need to curtail this or at least prevent reuse. It's probably not wise to rely on this. That sounds like for a usable certified system RIP might be out of scope? Hmm. Hope not. Right. The security policy is part of the authorization system. The authorization system, or at least a CC-complient authorization system should probably grow a principal-removal API. Well. If that would be an authorization system that would not be helpful in everyday business, then growing one only for CC would be beside the point of the certification to assure people that the system they use on a daily basis matches their security expectations. Christian -- gocept gmbh co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Certification: Supporting Residual Information Protection in Zope 3
Christian Theune wrote: Hi, Am Freitag, den 16.12.2005, 07:49 -0500 schrieb Jim Fulton: Christian Theune wrote: I think if we can guarantee never to reuse a user id, provide a tool for doing RIP and we do not provide undo we are fine. Only if we manage the user ids. We often get principal ids from outside sources. In fact, we usually do this in production. In the case when we're using an external principal soure, we also don't autmatically know when the principal is removed. Also, current principal-management facilities in Zope 3 allow managers to pick ids. We probably would need to curtail this or at least prevent reuse. It's probably not wise to rely on this. That sounds like for a usable certified system RIP might be out of scope? Hmm. Hope not. There could be a UI for removing principal grants that a manager could use to remove grants after a principal has been removed externally. Right. The security policy is part of the authorization system. The authorization system, or at least a CC-complient authorization system should probably grow a principal-removal API. Well. If that would be an authorization system that would not be helpful in everyday business, then growing one only for CC would be beside the point of the certification to assure people that the system they use on a daily basis matches their security expectations. I'm not conviced that this is an every-day requirement. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
