Univention Bugzilla – Bug 11800
Disallow users with username root
Last modified: 2021-06-23 07:29:14 CEST
Der Nutzername root sollte nicht mehr im UDM verwendet werden können, um Konflikte mit dem normalen root-Nutzer zu vermeiden.
In UDM/UMC wird Administrator als Benutzername verwendet. root kann nur Systemeinstellungen vornehmen.
Ich kann über UMC weiterhin einen Benutzer mit uid=root anlegen → REOPEN.
Created attachment 8114 [details] Patch to check for POSIX user names In this patch, the server does not accept any user name that is already assigned to an existing POSIX user (including root).
(In reply to Julius Hinrichs from comment #3) > Created attachment 8114 [details] > Patch to check for POSIX user names > > In this patch, the server does not accept any user name that is already > assigned to an existing POSIX user (including root). Users are replicated to all systems in the domain. Every system has a different /etc/passwd file. Therefore using the "pwd" which has only local users of the system where the change is done would be incorrect. Also the place where the changes are done is incorrect as this would only work for changed via the UMC module but not via the UDM-CLI. The change has to be done in either: management/univention-directory-manager-modules/modules/univention/admin/handlers/users/user.py or: management/univention-directory-manager-modules/modules/univention/admin/syntax.py
Created attachment 8129 [details] Patch to check for default debian users In this patch, UDM will reject the names of all debian default users (hard-coded) both in the CLI and in the UMC.
This issue has been filed against UCS 3. UCS 3 is out of the normal maintenance and many UCS components have vastly changed in UCS 4. If this issue is still valid, please change the version to a newer UCS version otherwise this issue will be automatically closed in the next weeks.
Shouldn't we just better add a ldap constraint instead of checking this in UDM?
Awesome idea :-)
This has been fixed by adding the "unique" overlay module to the slapd.conf. A special filter is build on the constraint which causes that the unique constraint applies only to selected uid's which are set comma separated in the new UCR variable 'ldap/unique/uid'. So that the uid's are unique I added an object "cn=unique-uid,cn=univention,$ldap_base" containing all blacklisted uid's. By default only the "root" user has been added. Should we add all debian users, etc.? In UCS 4.3 where we want to add a global uniqueness of uid's in LDAP (Bug #26383) we can rewrite the settings/prohibited_usernames UDM handler so that it uses "cn=unique-uid,cn=univention,$ldap_base". univention-ldap (13.0.7-14): r81767 | Bug #11800: only restrict root by default; don't increase join script version r81748 | Bug #11800: enforce uniqueness on uid's specified in ldap/unqiue/uid univention-ldap.yaml: r81749 | YAML Bug #11800
> By default only the "root" user has been added. Should we add all debian users, etc.? One fix at a time. The topic of this bug is root.
I reverted the changes as they didn't work completely. I added a LDAP ACL which prevents access to attrs=uid value="root" for everyone (except cn=admin,$ldap_base because no LDAP ACL's are evaluated for that). This prevents that one can login e.g. via ssh with that account. univention-ldap.yaml: r82413 | YAML Bug #11800 univention-ldap (13.0.7-17): r82412 | Bug #11800: prevent access to uid=root r82411 | Bug #11800: revert changes
univention-ldap (13.0.7-17): > r82411 | Bug #11800: revert changes Ok > r82412 | Bug #11800: prevent access to uid=root The exploit still works after the update, because the slapd is not restarted.
Are you sure? Afaics the restart is done in management/univention-ldap/debian/univention-ldap-server.postinst ?
I could not reproduce this: root@master:~# pgrep -fl slapd 30869 slapd root@master:~# apt-get install univention-ldap-{server,config,client,acl-master} … root@master:~# pgrep -fl slapd 31737 slapd Please note: If you use cn=admin with /etc/ldap.secret the ACL is not evaluated because cn=admin is the rootdn. See slapd.access(5) "Be warned: the rootdn can always read and write EVERYTHING!"
Created attachment 9155 [details] root.ldif > Are you sure? Afaics the restart is done in management/univention-ldap/debian/univention-ldap-server.postinst ? Ok, I agree, I see the slapd restart in updater.log but you put the change into univention-ldap-acl-master which has a dependency on univention-ldap-server. > root@master:~# apt-get install univention-ldap-{server,config,client,acl-master} That might not peoperly simulate an univention-upgrade. At least I wouldn't test that way. > Please note: If you use cn=admin with /etc/ldap.secret the ACL is not evaluated because cn=admin is the rootdn. > See slapd.access(5) "Be warned: the rootdn can always read and write EVERYTHING!" Yeah, thanks for reminding me :-) I was not that naive, although it was tempting. This is pretty much exactly what I did: root@master10:~# ucr search --brief version/errata version/erratalevel: 144 root@master10:~# cat /etc/apt/sources.list # This file is not maintained via Univention Configuration Registry # and can be used to add further package repositories manually deb http://192.168.0.10/build2/ ucs_4.2-0-errata4.2-1/all/ deb http://192.168.0.10/build2/ ucs_4.2-0-errata4.2-1/$(ARCH)/ deb-src http://192.168.0.10/build2/ ucs_4.2-0-errata4.2-1/source/ root@master10:~# ucr set update/secure_apt='no' Setting update/secure_apt File: /etc/apt/apt.conf.d/20secureapt root@master10:~# univention-upgrade Starting univention-upgrade. Current UCS version is 4.2-1 errata144 Checking for local repository: none Checking for package updates: found The following packages will be installed: python-pexpect The following packages will be upgraded: libpq5,univention-management-console-module-apps,univention-apache,univention-web-js,univention-web-style,univention-management-console-login,univention-management-console-frontend,univention-base-packages,shell-univention-lib,python-univention-lib,univention-base-files,univention-management-console-web-server,univention-management-console-module-updater,univention-updater,univention-management-console-module-join,univention-join,univention-management-console,univention-management-console-server,python-univention-management-console,univention-management-console-module-setup,univention-system-setup,univention-management-console-module-diagnostic,univention-management-console-module-appcenter,univention-appcenter-docker,univention-appcenter,python-univention-appcenter,univention-ldap-acl-master,univention-ldap-server,univention-ldap-config,postgresql-client-9.1,postgresql-client-9.4,univention-samba4,univention-samba4-sysvol-sync,univention-s4-connector,python-univention-connector-s4,python-univention-directory-reports,univention-directory-reports,univention-firewall,univention-ldap-client Do you want to continue [Y|n]? Starting package upgrade done Starting univention-upgrade. Current UCS version is 4.2-1 errata144 Checking for local repository: none Checking for package updates: none Checking for app updates: none Checking for release updates: none Setting update/available root@master10:~# dpkg -l univention-ldap-server | tail -1 ii univention-ldap-server 13.0.7-17A~4.2.0.201708221437 all UCS - LDAP server configuration root@master10:~# grep root /etc/ldap/slapd.conf rootdn "cn=admin,dc=ar41i1,dc=qa" access to attrs=uid value=root by * none stop root@master10:~# udm users/user modify \ --dn uid=Administrator,cn=users,dc=ar41i1,dc=qa \ --set password=FooBar123 Object modified: uid=Administrator,cn=users,dc=ar41i1,dc=qa root@master10:~# univention-ldapsearch uid=Administrator \ > root.ldif root@master10:~# vim root.ldif ## Adjust for root, see attachment root@master10:~# ldapadd -D uid=Administrator,cn=users,dc=ar41i1,dc=qa \ -w FooBar123 -f root.ldif adding new entry "uid=root,cn=users,dc=ar41i1,dc=qa" root@master10:~# ldapwhoami -D uid=root,cn=users,dc=ar41i1,dc=qa -w FooBar123 dn:uid=root,cn=users,dc=ar41i1,dc=q root@master10:~# ldapdelete -D uid=Administrator,cn=users,dc=ar41i1,dc=qa -w FooBar123 uid=root,cn=users,dc=ar41i1,dc=qa root@master10:~# /etc/init.d/slapd restart [ ok ] Restarting slapd (via systemctl): slapd.service. root@master10:~# ldapadd -D uid=Administrator,cn=users,dc=ar41i1,dc=qa \ -w FooBar123 -f 1.ldif adding new entry "uid=root,cn=users,dc=ar41i1,dc=qa" ldap_add: Insufficient access (50) additional info: no write access to attribute
The reason is Bug #45292. univention-ldap (13.0.7-19): r82535 | Bug #11800: fix ucslint postinst r82534 | Bug #11800: restart slapd during this upgrade in postinst univention-ldap-acl-master (13.0.7-19A~4.2.0.201708301301) wird eingerichtet ...^M Neue Version der Konfigurationsdatei /etc/univention/templates/files/etc/ldap/slapd.conf.d/60univention-ldap-server_acl-master wird installiert ...^M Multifile: /etc/ldap/slapd.conf^M Stopping slapd (via systemctl): slapd.service.^M Starting slapd (via systemctl): slapd.service.^M dist-update finished at Wed Aug 16 07:16:09 2017...
Ok, works.
<http://errata.software-univention.de/ucs/4.2/162.html>