Univention Bugzilla – Bug 18500
slapd running as root
Last modified: 2019-12-10 11:17:57 CET
slapd sollte als openldap ausgeführt werden.
Wenn dies umgesetzt wird, sollten die Änderungen aus Bug #17705 aus dem init-Skript entfernt und in die /etc/security/limits.conf migriert werden. (Siehe auch Bug #12928)
Still true with UCS-4.1
This issue has been filled against UCS 4.1. The maintenance with bug and security fixes for UCS 4.1 has ended on 5st of April 2018. Customers still on UCS 4.1 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.
Still true with UCS 4.2, 4.3, 4.4. This is a CWE-272 violation the "Principle of least privilege": Running a network facing daemon "needlessly" as root is waiting for disaster.
Hi The init script in UCS's upstream Debian is quite different (or UCS has diverged over time). Debian sources /etc/default/slapd and hence runs slapd as user 'openldap' for years, the earliest release I've checked was Debian 5. I've made an initial attempt at synchronizing UCS specific functions into Debian's init script and have proposed a WiP pull request: https://github.com/univention/univention-corporate-server/pull/14 There are some leftovers that I haven't done since some of them I cannot test like the i686 workaround since the last installable 32-bit version goes back to UCS 3.3 or 4.0. Hence why the PR is considered work in progress. The most daunting task would be to have a migration path and update documentation like the CA renewal since we have to move the certificates used by slapd to a folder under control of the user openldap. Maybe we could mis-use the init script to check and in case they are missing/differing copy the files from the UCS CA folder to /etc/ldap/ssl before starting slapd? I have done some initial testing with manually copying the certificates. slapd starts and stops for what I can tell but this doesn't cover a full QA. -- Mathieu
First of all: tank you for your work. (In reply to Mathieu Simon from comment #5) > The init script in UCS's upstream Debian is quite different (or UCS has > diverged over time). Debian sources /etc/default/slapd and hence runs slapd > as user 'openldap' for years, the earliest release I've checked was Debian 5. > > I've made an initial attempt at synchronizing UCS specific functions into > Debian's init script and have proposed a WiP pull request: > https://github.com/univention/univention-corporate-server/pull/14 We have added several checks to the init script in the past to make OpenLDAP more robust for UCS, like checking the DB for consistency, re-applying failed.ldif, ... We did not merge the changes from Debian as my work for Bug #46120 was too late for UCS-4.3. > The most daunting task would be to have a migration path and update > documentation like the CA renewal since we have to move the certificates > used by slapd to a folder under control of the user openldap. Maybe we could > mis-use the init script to check and in case they are missing/differing copy > the files from the UCS CA folder to /etc/ldap/ssl before starting slapd? Debian has the group "ssl-cert" for that, which owns the certificate files. Any service needed access to them is added to that group. UCS should do the same.
Hi Philipp > We have added several checks to the init script in the past to make OpenLDAP > more robust for UCS, like checking the DB for consistency, re-applying > failed.ldif, ... I've seen them, for most things and except for that i686 workaround I've tried to get them back in the best I could in the start) section. > We did not merge the changes from Debian as my work for Bug #46120 was > too late for UCS-4.3. The question being if such a change would be acceptable during a patch update like currently 4.4-1 or not. That is only you folks at Univention who can decide. I hope we can to a point where we come up with an acceptable MR. Changing the user in the start) section would be possible with less invasive changes if that's preferred way of getting this fix in. - Though that still requires thinking about the certificate permission changes. I'd definitely need your input and review on where you are missing things and would prefer them to be done instead. Most of these additional things workarounds certainly a reason/story that I may not be aware of. > Debian has the group "ssl-cert" for that, which owns the certificate files. > Any service needed access to them is added to that group. > UCS should do the same. Yes, currently that isn't the case for the user openldap. Debian's slapd packages handles adding openldap user and group via slapd.postinst, the used functions are again found in slapd.scripts-common. (slapd.postrm doesn't remove the user and group.) In order to avoid further modification of the slapd package and since univention-ldap-server already pre-depends on slapd, could this be done within the postinst of univention-ldap-server? I've pushed a proposal in a commit on how to add openldap to the ssl-cert group. (Only covers the group membership aspect) -- Mathieu