Univention Bugzilla – Bug 41180
user can create arbitrary objects in cn=admin-settings,cn=univention
Last modified: 2021-06-23 07:29:06 CEST
Every user has the LDAP permissions to create arbitrary objects in uid=$USERNAME,cn=admin-settings,cn=univention,$ldap_base which have at least the uid attribute. E.g. I could add the following: uid=tim2,cn=admin-settings,cn=univention,dc=school,dc=local objectClass: CourierMailAccount objectClass: organizationalRole uid: tim2 uidNumber: 0 gidNumber: 0 cn: foo With this I might be able to construct some evil objects. We should restrict this to objectClass == "univentionAdminUserSettings".
ucs-test (6.0.35-3): r70877 | Bug #41180: also catch OBJECT_CLASS_VIOLATION as now a content rule for 'univentionAdminUserSettings' exists r70779 | Bug #41180: add 61_udm-users/30_user_admin_setting_acl r70778 | Bug #41180: fix ucs-test build r70777 | Bug #41180: add missing executable flag r70764 | Bug #41180: restrict also creation of cn=admin-settings entries univention-ldap (12.1.6-28): r70863 | Bug #41180: remove write access to pseudo-attribute 'entry' of cn=admin-settings,cn=univention r70849 | Bug #41180: Add content rule to 'univentionAdminUserSettings' and 'univentionAdminGlobalSettings' r70764 | Bug #41180: restrict also creation of cn=admin-settings entries r70608 | Bug #41180: restrict access to uid=*,cn=admin-settings to objects with univentionAdminUserSettings object class univention-ldap.yaml: r70609 | YAML Bug #41179, Bug #41180
svn r71020 reverted "add_content_acl on" in slapd.conf. This will be fixed by Bug #41797. Until then the restriction works only for modifications.
In my tests I see that the new ACLs deny DC Slaves (and probably Memberservers) from replicating the (objectClass=univentionAdminUserSettings) objects below "cn=admin-settings,cn=univention,$ldap_base" While I don't think that the world will collapse about this, I'm not sure that this is intended behaviour? Adding Stefan on CC for a second opinion.
For the same reason univention-ldapsearch -x doesn't show those objects any longer (because it's done with an unprivileged machine account). The objects are replicated to DC Backups though, because they read as cn=admin.
(In reply to Arvid Requate from comment #3) > In my tests I see that the new ACLs deny DC Slaves (and probably > Memberservers) from replicating the > (objectClass=univentionAdminUserSettings) objects below > > "cn=admin-settings,cn=univention,$ldap_base" > > While I don't think that the world will collapse about this, I'm not sure > that this is intended behaviour? Adding Stefan on CC for a second opinion. The univentionAdminUserSettings objects were used for UCS 2.4 UDM / UMC. So it shouldn't be a problem.
Ok.
<http://errata.software-univention.de/ucs/4.1/222.html>
(In reply to Stefan Gohmann from comment #5) > (In reply to Arvid Requate from comment #3) > > In my tests I see that the new ACLs deny DC Slaves (and probably > > Memberservers) from replicating the > > (objectClass=univentionAdminUserSettings) objects below > > > > "cn=admin-settings,cn=univention,$ldap_base" > > > > While I don't think that the world will collapse about this, I'm not sure > > that this is intended behaviour? Adding Stefan on CC for a second opinion. > > The univentionAdminUserSettings objects were used for UCS 2.4 UDM / UMC. So > it shouldn't be a problem. It would have been a problem if DC Slaves could read them because then every user would have been able to create a domain wide root account.