Univention Bugzilla – Full Text Bug Listing |
Summary: | user can create arbitrary objects in cn=admin-settings,cn=univention | ||
---|---|---|---|
Product: | UCS | Reporter: | Florian Best <best> |
Component: | LDAP | Assignee: | Florian Best <best> |
Status: | CLOSED FIXED | QA Contact: | Arvid Requate <requate> |
Severity: | normal | ||
Priority: | P5 | CC: | gohmann |
Version: | UCS 4.1 | ||
Target Milestone: | UCS 4.1-2-errata | ||
Hardware: | Other | ||
OS: | Linux | ||
See Also: | https://forge.univention.org/bugzilla/show_bug.cgi?id=31048 | ||
What kind of report is it?: | Security Issue | What type of bug is this?: | --- |
Who will be affected by this bug?: | --- | How will those affected feel about the bug?: | --- |
User Pain: | Enterprise Customer affected?: | ||
School Customer affected?: | ISV affected?: | ||
Waiting Support: | Flags outvoted (downgraded) after PO Review: | ||
Ticket number: | Bug group (optional): | Security | |
Max CVSS v3 score: |
Description
Florian Best
2016-04-29 17:00:45 CEST
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. (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. |