Hi, I am going to publish this as a blog post in the next few days on http://firstyear.id.au However, as it's relevant for this audience I decided to re-post it here. My workplace is a reasonably sized consumer of 389ds. We use it for storing pretty much all our most important identity data from allowing people to authenticate, to group and course membership, to email routing and even internet access. As a result, it's a really important service to maintain. We need to treat it as one of the most security sensitive services we run. The definition of security I always come back to is "availability, integrity and confidentiality". Now, we have a highly available environment, and we use TLS with our data to ensure confidentiality of results and queries. Integrity however, is the main target of this post. LDAP allows objects that exist with in the directory to "bind" (authenticate) and then to manipulate other objects in the directories. A set of ACIs (Access Control Instructions) define what objects can modify other objects and their attributes. ACIs are probably one of the most complex parts in a directory server environment to "get right" (With the exception maybe of VLV). I noticed during a security review of our directories ACIs that took the following pattern. aci: (targetattr !="cn")(version 3.0;acl "Self write all but cn";allow (write)(userdn = "ldap:///self");) aci: (targetattr !="sn")(version 3.0;acl "Self write all but sn";allow (write)(userdn = "ldap:///self");) Now, the rules in question we had were more complex and had more rules, but at their essence looked like this. Seems like an innocuous set of rules. "Allow self write to everything but sn" and "Allow self write to everything but cn". So at the end we expect to see we can write everything but sn and cn. Lets use the ldap effective permissions capability to check this: /usr/lib64/mozldap/ldapsearch -D 'cn=Directory Manager' -w - -b 'cn=test,ou=people,dc=example,dc=net,dc=au' -J "1.3.6.1.4.1.42.2.27.9.5.2:false:dn: cn=test,ou=people,dc=example,dc=net,dc=au" "(objectClass=*)" version: 1 dn: cn=test,ou=People,dc=example,dc=net,dc=au objectClass: top objectClass: person cn: test sn: test userPassword: entryLevelRights: v attributeLevelRights: objectClass:rscwo, cn:rscwo, sn:rscwo, userPassword:wo What! Why does cn have r[ead] s[search] c[ompare] w[rite] o[bliterate]? That was denied? Same for SN. Well, LDAP treats ACIs as a positive union. So we have: aci 1 = ( objectclass, sn, userpassword) aci 2 = ( objectclass, cn, userpassword) aci 1 U aci 2 = ( objectclass, sn, cn, userpassword ) As a result, our seemingly secure rules, actually were conflicting and causing our directory to be highly insecure! So, easy to change this: First we invert the rules (be explicit in all things) to say targetattr = "userpassword" for example. We shouldn't use != rules because they can even conflict between groups and self. How do we detect these issues though? I wrote a python library called usl (university simple ldap). In this I have a toolset for unit testing our ldap acis. We create a py.test testcase, that states for some set of objects, they should have access to some set of attributes on a second set of objects. IE group admins should have rscwo on all other objects. We can then run these tests and determine if this is or isn't the case. For example, if we wrote two test cases for the above to test that "self has rscwo to all attributes or self except sn which should be rsc" and a second test "self has rscwo to all attributes or self except cn which should be rsc". Our test cases would have failed, and we would be alerted to these issues. As a result of these tests for our acis I was able to find many more security issues: Such as users who could self modify groups, self modify acis, account lockouts of other users, or even turn themselves into a container object and create children. At the worst one aci actually allowed objects to edit their own aci's which would have allowed them to give themself more access potentially. The largest offender were rules that defined targetattr != rules: Often these were actually allowing access to write attributes that administrators would over look. For example, the rule above allowing all write except cn, would actually allow access to nsAccountLock, nsSizeLimit and other object attributes that don't show up on first inspection. The complete list is below. (Note the addition of the '+' ) /usr/lib64/mozldap/ldapsearch -D 'cn=Directory Manager' -w - -b 'cn=test,ou=people,dc=example,dc=net,dc=au' -J "1.3.6.1.4.1.42.2.27.9.5.2:false:dn: cn=test,ou=people,dc=example,dc=net,dc=au" "(objectClass=*)" '+' version: 1 dn: cn=test,ou=People,dc=example,dc=net,dc=au entryLevelRights: v attributeLevelRights: nsPagedLookThroughLimit:rscwo, passwordGraceUserTime:rsc wo, pwdGraceUserTime:rscwo, modifyTimestamp:rscwo, passwordExpWarned:rscwo, pwdExpirationWarned:rscwo, internalModifiersName:rscwo, entrydn:rscwo, dITCo ntentRules:rscwo, supportedLDAPVersion:rscwo, altServer:rscwo, vendorName:rs cwo, aci:rscwo, nsSizeLimit:rscwo, attributeTypes:rscwo, acctPolicySubentry: rscwo, nsAccountLock:rscwo, passwordExpirationTime:rscwo, entryid:rscwo, mat chingRuleUse:rscwo, nsIDListScanLimit:rscwo, nsSchemaCSN:rscwo, nsRole:rscwo , retryCountResetTime:rscwo, tombstoneNumSubordinates:rscwo, supportedFeatur es:rscwo, ldapSchemas:rscwo, copiedFrom:rscwo, nsPagedIDListScanLimit:rscwo, internalCreatorsName:rscwo, nsUniqueId:rscwo, lastLoginTime:rscwo, creators Name:rscwo, passwordRetryCount:rscwo, dncomp:rscwo, vendorVersion:rscwo, nsT imeLimit:rscwo, passwordHistory:rscwo, pwdHistory:rscwo, objectClasses:rscwo , nscpEntryDN:rscwo, subschemaSubentry:rscwo, hasSubordinates:rscwo, pwdpoli cysubentry:rscwo, structuralObjectClass:rscwo, nsPagedSizeLimit:rscwo, nsRol eDN:rscwo, createTimestamp:rscwo, accountUnlockTime:rscwo, dITStructureRules :rscwo, supportedSASLMechanisms:rscwo, supportedExtension:rscwo, copyingFrom :rscwo, nsLookThroughLimit:rscwo, nsds5ReplConflict:rscwo, modifiersName:rsc wo, matchingRules:rscwo, governingStructureRule:rscwo, entryusn:rscwo, nssla pd-return-default-opattr:rscwo, parentid:rscwo, pwdUpdateTime:rscwo, support edControl:rscwo, passwordAllowChangeTime:rscwo, nsBackendSuffix:rscwo, nsIdl eTimeout:rscwo, nameForms:rscwo, ldapSyntaxes:rscwo, numSubordinates:rscwo, namingContexts:rscwo As a result of unit testing our ldap aci's we were able to find many many loop holes in our security, and then we were able to programatically close them all down. Reading the ACI's by hand revealed some issues, but by testing the "expected" aci versus actual behaviour highlighted our edge cases and the complex interactions of LDAP systems. I will clean up and publish the usl tool set in the future to help other people test their own LDAP secuity controls.

>> I will clean up and publish the usl tool set in the future to help >> other people test their own LDAP secuity controls. >> >> > Nice! This would be a good addition to our admin/management tools, > if > you would like to submit it. Please open a ticket and attach the > code > to it (or just point us to your github or wherever you are hosting > this). Might I suggest the name "audit_acis"? > It needs a lot of work before it can be added: At the moment you have to hand define your acis in the system to actually test. My future work will be to make this read the set of acis and auto -generate tests from these. This will be able to: * Automatically find potentially conflicting acis * List all attributes that an aci provides access to on target objects * Make it a lot easier to "drop in" and use. Once I've done this, I'll certainly make it available. At the same time, I have some other python tools to submit also.

Glad that you liked it! -- 389 users mailing list 389-users(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users