Full_Name: Daniel Pluta Version: MASTER OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:9feb:ff03:e455:e36f:5b06:b2f1) The "Enhancement for dnattr=... ACL" we've described within the LDAPcon2011 paper (http://www.daasi.de/ldapcon2011/downloads/plutahommelweinert-paper.pdf, Chapter VI, Section G., pdf page 7, left column bottom) seems to be still very useful in our opinion. We (Peter an me) have discussed the idea behind this enhancement together with Howard during dinner the day before the LDAPCon2011 officially started. We described the enhancement as some kind of "dnattr-based-administrator-less-2-way-handshake-entry-responsibility(-owner)-transition". Until today ITS#6900 contains a prototypical patch (very dirty hack), to demonstrate the described enhancement's mode of operation. The good news: Probably this hack isn't needed anymore in the future and thus ITS#6900 could be closed, but just in case ... The bad news: ... another (hopefully) less intrusive and generally useful patch, that seems to be implementable without introducing new keywords can be realized instead: In http://www.openldap.org/lists/openldap-technical/201208/msg00040.html Kurt explained that the acl privilege levels "a" and "z" share one bit with the "w" privilege's bit set. Thus currently neither "a" nor "z" can be independently substracted from "w" in the way either "z" or "a" remains in the privilege set. Subtracting "a" or "z" results in removing the complete "w" privilege (including "a" and "z"). In case the bit masks of the privileges "a", "z", and "w" can be separated (introducing exclusive masks for ACL_WADD, ACL_WDEL and ACL_WRITE), the following acl set offers the above described mode of operation (out-of-the-box without the need to apply the hack submitted with ITS#6900): {0}to dn.base="ou=groups,o=iacm" attrs=children by users write by * none {1}to dn.one="ou=groups,o=iacm" attrs=owner by dnattr=owner =dxcsraz continue by dnattr=modifiersName -z by * none {2}to dn.one="ou=groups,o=iacm" attrs=entry,@groupOfNames by dnattr=owner write by * none I've not been able to test this acls yet (due to no available hack/patch). At least in theory it should represent the mentioned enhancement's mode of operation: The owner attribute can be modified (add and delete) by any owner, but no owner can remove himself from the owner attribute to either repudiate his personal responsibility for an entry or to produce a dangling entry (an administrator needs to clean up), in case it's the last owner. Herewith, the request for a more detailed description of a usecase where substractive privileges are of general use should be answered. Additionally I also thought about the statement, that "good ACLs" are either static or additive: I have not been able to find a static or additive ACL solution to implement the above described functionality in a similar elegant way (e.g. without administratively maintained group patterns). Alternative 1: (elegant static/additive ACL) There possibly exists a solution to express the above described mode of operation already nowadays by using static and additive acls only, if so, I appreciate any advice. Alternative 2: (coding the bitmask-separation) I have no clue how(h)ard ;-) it is to implement (especially test) a successfull separation of these bit masks. It was mentioned that the incremental processing of privileges has been added later and the underlying design could be suboptimal. Currently I don't know which pitfalls to be aware of (especially in and around acl.c). Nevertheless and depending on the answer to alternative 1, I'm interessted to give it a try, thus any thoughts and hints are very welcome, too. Thanks a lot!
On Aug 6, 2012, at 1:55 PM, daniel@pluta.biz wrote: > Full_Name: Daniel Pluta > Version: MASTER > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:470:9feb:ff03:e455:e36f:5b06:b2f1) > > > The "Enhancement for dnattr=... ACL" we've described within the LDAPcon2011 > paper (http://www.daasi.de/ldapcon2011/downloads/plutahommelweinert-paper.pdf, > Chapter VI, Section G., pdf page 7, left column bottom) seems to be still very > useful in our opinion. > > We (Peter an me) have discussed the idea behind this enhancement together with > Howard during dinner the day before the LDAPCon2011 officially started. We > described the enhancement as some kind of > "dnattr-based-administrator-less-2-way-handshake-entry-responsibility(-owner)-transition". > > Until today ITS#6900 contains a prototypical patch (very dirty hack), to > demonstrate the described enhancement's mode of operation. > > The good news: > Probably this hack isn't needed anymore in the future and thus ITS#6900 could be > closed, but just in case ... > > The bad news: > ... another (hopefully) less intrusive and generally useful patch, that seems to > be implementable without introducing new keywords can be realized instead: > > In http://www.openldap.org/lists/openldap-technical/201208/msg00040.html Kurt > explained that the acl privilege levels "a" and "z" share one bit with the "w" > privilege's bit set. Thus currently neither "a" nor "z" can be independently > substracted from "w" in the way either "z" or "a" remains in the privilege set. > Subtracting "a" or "z" results in removing the complete "w" privilege (including > "a" and "z"). Looking back at the devel discussion about the introduction of a/z privs (April 2005), there seems to have been no consideration of subtractive access controls. That is, I think the we all just missed the a/z feature was not implemented in a manner which supported subtractive access controls. Or, more simply put, whoops. Using qualifiers was the mistake. Just should of replaced one bit with 2 bits, with some operations requesting one or the other or both bits. > In case the bit masks of the privileges "a", "z", and "w" can be separated > (introducing exclusive masks for ACL_WADD, ACL_WDEL and ACL_WRITE), the > following acl set offers the above described mode of operation (out-of-the-box > without the need to apply the hack submitted with ITS#6900): > > {0}to dn.base="ou=groups,o=iacm" attrs=children by users write by * none > {1}to dn.one="ou=groups,o=iacm" attrs=owner by dnattr=owner =dxcsraz continue > by dnattr=modifiersName -z by * none > {2}to dn.one="ou=groups,o=iacm" attrs=entry,@groupOfNames by dnattr=owner write > by * none > > I've not been able to test this acls yet (due to no available hack/patch). At > least in theory it should represent the mentioned enhancement's mode of > operation: > The owner attribute can be modified (add and delete) by any owner, but no owner > can remove himself from the owner attribute to either repudiate his personal > responsibility for an entry or to produce a dangling entry (an administrator > needs to clean up), in case it's the last owner. I'd have to think a bit harder whether the access controls above implement this properly, but I am sure {1} can be written using non-substractive ACLs. Off hand, probably requiring two to do it. > Herewith, the request for a more detailed description of a usecase where > substractive privileges are of general use should be answered. The general use case of additive and subtractive ACL is that it sometimes makes ACLs shorter. > Additionally I > also thought about the statement, that "good ACLs" are either static or > additive: I think I used the word "should", as in subtractive ACLs should be avoided. There are likely cases where their use can be well justified, just like default grant rules can sometimes be well justified. However, many security experts advise use of explicit grants (=) or additive (+) grants. I generally concur with this advice. > I have not been able to find a static or additive ACL solution to > implement the above described functionality in a similar elegant way (e.g. > without administratively maintained group patterns) > > Alternative 1: (elegant static/additive ACL) > There possibly exists a solution to express the above described mode of > operation already nowadays by using static and additive acls only, if so, I > appreciate any advice. > > Alternative 2: (coding the bitmask-separation) > I have no clue how(h)ard ;-) it is to implement (especially test) a successfull > separation of these bit masks. It was mentioned that the incremental processing > of privileges has been added later and the underlying design could be > suboptimal. Currently I don't know which pitfalls to be aware of (especially in > and around acl.c). Nevertheless and depending on the answer to alternative 1, > I'm interessted to give it a try, thus any thoughts and hints are very welcome, > too. The latter should be the preferred approach, IMO. The question I would have is wether an implementation of such would have any negative impact upon deployments. That's a real hard one to access, as deployments do some pretty crazy things. In short, it comes does to whether anyone does =w continue followed by -a or -z and expecting the outcome not to z or a respectively. -- Kurt > > Thanks a lot! >
I've uploaded a quick workaround to check the above acl, it can be downloaded from here: ftp://ftp.openldap.org/incoming/its7347.patch => Test result: It works for me. In the sense of the ITS title it's just a half-way workaround: It addresses only subtractive ACLs, additive ACLs are not addressed. A clean solution, separating the bitmasks is of course preferable. In my opinion ITS#6900 should be closed.
Applying the patch accessible here: ftp://ftp.openldap.org/incoming/Daniel-Pluta-120808.patch together with the acl set below obsoletes ITS#6900. In combination they enable the mode of operation we described in section VI, subsection G. of the previously linked paper. to dn.base="ou=groups,o=test" attrs=children by users write by * none to dn.one="ou=groups,o=test" attrs=owner by dnattr=owner write continue by dnattr=owner self-z by * none break to dn.one="ou=groups,o=test" attrs=entry,@groupOfNames by dnattr=owner write by * none The patch enables support to independently substract the privileges 'z' or 'a' from 'w', while 'a' or 'z' remain in the resulting bit mask. The other way around, adding 'a' or 'z' privs is also supported. Nevertheless, in the sense of the subject of this ITS the patch represents only a workaround. A clean solution (separating the 'a', 'z' and 'w' bitmasks) is of course preferable. LDIF test cases using ldapmodify command: ldapmodify -x -D "cn=000001,ou=persons,o=test" ... #create group entry (should fail) dn: cn=its7347-fail,ou=groups,o=test changetype: add cn: its7347 objectClass: top objectClass: groupOfNames member: cn=000001,ou=persons,o=test owner: cn=000002,ou=persons,o=test #create group entry (should succeed) dn: cn=its7347-success,ou=groups,o=test changetype: add cn: its7347 objectClass: top objectClass: groupOfNames member: cn=000001,ou=persons,o=test owner: cn=000001,ou=persons,o=test #add another owner (should succeed) dn: cn=its7347-success,ou=groups,o=test changetype: modify add: owner owner: cn=000002,ou=persons,o=test #delete the other owner (should succeed) dn: cn=its7347-success,ou=groups,o=test changetype: modify delete: owner owner: cn=000002,ou=persons,o=test #delete the entry (should succeed) dn: cn=its7347-success,ou=groups,o=test changetype: delete #restore the group (should succeed) dn: cn=its7347-success,ou=groups,o=test changetype: add cn: its7347 objectClass: top objectClass: groupOfNames member: cn=000001,ou=persons,o=test owner: cn=000001,ou=persons,o=test owner: cn=000002,ou=persons,o=test #delete the entry (should succeed) dn: cn=its7347-success,ou=groups,o=test changetype: delete #again restore the entry (should succeed) dn: cn=its7347-success,ou=groups,o=test changetype: add cn: its7347 objectClass: top objectClass: groupOfNames member: cn=000001,ou=persons,o=test owner: cn=000001,ou=persons,o=test owner: cn=000002,ou=persons,o=test #try to delete the owner (should fail) dn: cn=its7347-success,ou=groups,o=test changetype: modify delete: owner owner: cn=000001,ou=persons,o=test #delete the entry (should succeed) dn: cn=its7347-success,ou=groups,o=test changetype: delete
For 2.5?
changed notes moved from Incoming to Software Enhancements
Although I know that I'm highly probable not directly addressed by the question "For 2.5?" (see this its's notes), my answer/comment would be "Yes", even "Yes, of course.": As I think, introducing this feature into a later 2.5.x release seems to be as problematic as its introduction into running 2.4.x, I think it is a good or perhaps the best opportunity to introduce this feature into the first 2.5, or 2.6, ... or 3.0 release. Disclaimer (again): I do not mean applying my patch, which represents just a workaround for demonstration/testing purposes. Sorry, I don't know how to code the "the bitmask-separation" - but I could and would help testing it. By the way: Thank you very much for taking care of the its' incoming queue!
--On Monday, April 10, 2017 9:36 AM +0000 daniel@pluta.biz wrote: > Although I know that I'm highly probable not directly addressed by the > question "For 2.5?" (see this its's notes), my answer/comment would be > "Yes", even "Yes, of course.": Hi Daniel, It's just a note to myself to discuss with Howard for possible inclusion in 2.5. ;) I'm going through all the incoming ITSes and sorting them out and setting priority, etc, as that's been neglected for a while. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Created attachment 626 [details] its7347.patch
Created attachment 627 [details] daniel-pluta-2012-08-08.patch