Bug 11800 - Disallow users with username root
Disallow users with username root
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: UMC - Users
UCS 4.2
All Linux
: P4 normal (vote)
: UCS 4.2-2-errata
Assigned To: Florian Best
Arvid Requate
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-04 13:14 CEST by Jan Christoph Ebersbach
Modified: 2021-06-23 07:29 CEST (History)
6 users (show)

See Also:
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:
requate: Patch_Available+


Attachments
Patch to check for POSIX user names (1.74 KB, patch)
2016-10-17 14:27 CEST, Julius Hinrichs
Details | Diff
Patch to check for default debian users (1.16 KB, patch)
2016-10-18 17:49 CEST, Julius Hinrichs
Details | Diff
root.ldif (635 bytes, text/x-ldif)
2017-08-29 22:59 CEST, Arvid Requate
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Christoph Ebersbach univentionstaff 2008-08-04 13:14:44 CEST
Der Nutzername root sollte nicht mehr im UDM verwendet werden können, um Konflikte mit dem normalen root-Nutzer zu vermeiden.
Comment 1 Florian Best univentionstaff 2011-12-13 15:59:52 CET
In UDM/UMC wird Administrator als Benutzername verwendet. root kann nur Systemeinstellungen vornehmen.
Comment 2 Alexander Kläser univentionstaff 2011-12-15 15:23:25 CET
Ich kann über UMC weiterhin einen Benutzer mit uid=root anlegen → REOPEN.
Comment 3 Julius Hinrichs univentionstaff 2016-10-17 14:27:27 CEST
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).
Comment 4 Florian Best univentionstaff 2016-10-17 14:40:54 CEST
(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
Comment 5 Julius Hinrichs univentionstaff 2016-10-18 17:49:48 CEST
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.
Comment 6 Stefan Gohmann univentionstaff 2017-06-16 20:39:14 CEST
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.
Comment 7 Florian Best univentionstaff 2017-07-05 14:07:24 CEST
Shouldn't we just better add a ldap constraint instead of checking this in UDM?
Comment 8 Arvid Requate univentionstaff 2017-07-05 17:11:49 CEST
Awesome idea :-)
Comment 9 Florian Best univentionstaff 2017-08-03 15:45:38 CEST
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
Comment 11 Arvid Requate univentionstaff 2017-08-03 16:15:23 CEST
> 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.
Comment 13 Florian Best univentionstaff 2017-08-22 14:41:36 CEST
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
Comment 14 Arvid Requate univentionstaff 2017-08-28 20:44:27 CEST
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.
Comment 15 Florian Best univentionstaff 2017-08-29 13:41:43 CEST
Are you sure? Afaics the restart is done in management/univention-ldap/debian/univention-ldap-server.postinst ?
Comment 16 Florian Best univentionstaff 2017-08-29 16:32:45 CEST
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!"
Comment 17 Arvid Requate univentionstaff 2017-08-29 22:59:01 CEST
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
Comment 18 Florian Best univentionstaff 2017-08-30 13:05:51 CEST
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...
Comment 19 Arvid Requate univentionstaff 2017-09-06 19:19:30 CEST
Ok, works.
Comment 20 Arvid Requate univentionstaff 2017-09-13 16:35:01 CEST
<http://errata.software-univention.de/ucs/4.2/162.html>