I'm testing openldap 2.5 in preparation for migration my production services, and I noticed that the 2.5 RPMs no longer create an ldap user and instead run slapd as root by default? Is this because they're no longer intended to replace the system bundled openldap packages? It seems undesirable from a security perspective to run slapd as root rather than a dedicated service account.
I see there's a note about updating the startup options to run as a service account here:
https://repo.symas.com/soldap/systemd/
but the ldap user/group used as an example won't exist unless the system RPMs or the 2.4 RPMs have been previously installed or the user is created manually.
--On Tuesday, October 19, 2021 1:00 AM -0700 "Paul B. Henson" henson@acm.org wrote:
I'm testing openldap 2.5 in preparation for migration my production services, and I noticed that the 2.5 RPMs no longer create an ldap user and instead run slapd as root by default? Is this because they're no longer intended to replace the system bundled openldap packages? It seems undesirable from a security perspective to run slapd as root rather than a dedicated service account.
I see there's a note about updating the startup options to run as a service account here:
https://repo.symas.com/soldap/systemd/
but the ldap user/group used as an example won't exist unless the system RPMs or the 2.4 RPMs have been previously installed or the user is created manually.
If you want it to run as a non-root user, it's on you to configure it as such, including said user. The majority of Symas customers run as root. So yes, this is intentional and due to the fact that it's not attempting to be the replacement of the system bundled OpenLDAP. You're free to run things as best fits your environment.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 10/19/21 17:10, Quanah Gibson-Mount wrote:
--On Tuesday, October 19, 2021 1:00 AM -0700 "Paul B. Henson" henson@acm.org wrote:
I'm testing openldap 2.5 in preparation for migration my production services, and I noticed that the 2.5 RPMs no longer create an ldap user and instead run slapd as root by default?
If you want it to run as a non-root user, it's on you to configure it as such, including said user. The majority of Symas customers run as root.
IMHO there's no good reason to let systemd start slapd as root.
Binding to so-called "privileged ports" can be achieved by setting these options in the systemd unit:
CapabilityBoundingSet=CAP_NET_BIND_SERVICE AmbientCapabilities=CAP_NET_BIND_SERVICE
Also it's good practice to use systemd's sandboxing options based on Linux namespaces. Read about various options called Protect*= and Private*= in systemd.exec(5).
Nevertheless I also recommend to add a custom service account and set ownership/permissions with a decent config management instead of adding this to a RPM .spec or Debian package.
Find below ae-slapd.service generated by Æ-DIR's ansible role.
Ciao, Michael.
# /etc/systemd/system/ae-slapd.service #----------------------------------------------------------------------- # initiate: systemctl enable ae-slapd.service # start: systemctl start ae-slapd.service # get status: systemctl status ae-slapd.service # # Ansible managed: ansible-homelan/master #-----------------------------------------------------------------------
[Unit] Description=AE-DIR OpenLDAP server Requires=local-fs.target network.target After=local-fs.target network.target
[Service] Type=simple Environment=LD_PRELOAD=/usr/lib64/libtcmalloc.so.4 Environment=LDAPNOINIT=1 PIDFile=/run/ae-dir/slapd/slapd.pid ExecStart=/usr/lib64/slapd -d none -n ae-slapd -l LOCAL4 -s 7 -f /opt/ae-dir/etc/openldap/slapd.conf -h 'ldapi://%%2Frun%%2Fae-dir%%2Fslapd%%2Fldapi/????x-mod=0777 ldap://*:389 ldaps://*:636' -o slp=off WorkingDirectory=/run/ae-dir/slapd User=ae-dir-slapd Group=ae-dir-slapd CapabilityBoundingSet=CAP_NET_BIND_SERVICE AmbientCapabilities=CAP_NET_BIND_SERVICE LimitNOFILE=96 RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX # various hardening options from ansible var aedir_systemd_hardening UMask=0077 PrivateUsers=no PrivateTmp=yes PrivateDevices=yes ProtectSystem=full ProtectProc=invisible ProtectHome=yes ProtectKernelModules=yes ProtectKernelTunables=yes ProtectKernelLogs=yes ProtectControlGroups=yes ProtectHostname=yes ProtectClock=yes NoNewPrivileges=yes MountFlags=private SystemCallArchitectures=native LockPersonality=yes KeyringMode=private RestrictRealtime=yes RestrictNamespaces=yes RestrictSUIDSGID=yes DevicePolicy=closed MemoryDenyWriteExecute=yes SystemCallFilter=~ @clock @cpu-emulation @debug @keyring @module @mount @raw-io @reboot @swap @obsolete @chown @privileged @resources @pkey @setuid @timer AppArmorProfile=ae-slapd
[Install] WantedBy=multi-user.target
Hi!
Wondering about "LimitNOFILE=96": Wouldn't that limit the open sockets (connections) as well?
Regards, Ulrich
Michael Ströder michael@stroeder.com schrieb am 19.10.2021 um 18:17 in
Nachricht cfde6c8a-aee8-a5fa-02c6-5f5d6ecf0d3f@stroeder.com:
On 10/19/21 17:10, Quanah Gibson-Mount wrote:
--On Tuesday, October 19, 2021 1:00 AM -0700 "Paul B. Henson" henson@acm.org wrote:
I'm testing openldap 2.5 in preparation for migration my production services, and I noticed that the 2.5 RPMs no longer create an ldap user and instead run slapd as root by default?
If you want it to run as a non-root user, it's on you to configure it as such, including said user. The majority of Symas customers run as root.
IMHO there's no good reason to let systemd start slapd as root.
Binding to so-called "privileged ports" can be achieved by setting these options in the systemd unit:
CapabilityBoundingSet=CAP_NET_BIND_SERVICE AmbientCapabilities=CAP_NET_BIND_SERVICE
Also it's good practice to use systemd's sandboxing options based on Linux namespaces. Read about various options called Protect*= and Private*= in systemd.exec(5).
Nevertheless I also recommend to add a custom service account and set ownership/permissions with a decent config management instead of adding this to a RPM .spec or Debian package.
Find below ae-slapd.service generated by Æ-DIR's ansible role.
Ciao, Michael.
# /etc/systemd/system/ae-slapd.service #----------------------------------------------------------------------- # initiate: systemctl enable ae-slapd.service # start: systemctl start ae-slapd.service # get status: systemctl status ae-slapd.service # # Ansible managed: ansible-homelan/master #-----------------------------------------------------------------------
[Unit] Description=AE-DIR OpenLDAP server Requires=local-fs.target network.target After=local-fs.target network.target
[Service] Type=simple Environment=LD_PRELOAD=/usr/lib64/libtcmalloc.so.4 Environment=LDAPNOINIT=1 PIDFile=/run/ae-dir/slapd/slapd.pid ExecStart=/usr/lib64/slapd -d none -n ae-slapd -l LOCAL4 -s 7 -f /opt/ae-dir/etc/openldap/slapd.conf -h 'ldapi://%%2Frun%%2Fae-dir%%2Fslapd%%2Fldapi/????x-mod=0777 ldap://*:389 ldaps://*:636' -o slp=off WorkingDirectory=/run/ae-dir/slapd User=ae-dir-slapd Group=ae-dir-slapd CapabilityBoundingSet=CAP_NET_BIND_SERVICE AmbientCapabilities=CAP_NET_BIND_SERVICE LimitNOFILE=96 RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX # various hardening options from ansible var aedir_systemd_hardening UMask=0077 PrivateUsers=no PrivateTmp=yes PrivateDevices=yes ProtectSystem=full ProtectProc=invisible ProtectHome=yes ProtectKernelModules=yes ProtectKernelTunables=yes ProtectKernelLogs=yes ProtectControlGroups=yes ProtectHostname=yes ProtectClock=yes NoNewPrivileges=yes MountFlags=private SystemCallArchitectures=native LockPersonality=yes KeyringMode=private RestrictRealtime=yes RestrictNamespaces=yes RestrictSUIDSGID=yes DevicePolicy=closed MemoryDenyWriteExecute=yes SystemCallFilter=~ @clock @cpu-emulation @debug @keyring @module @mount @raw-io @reboot @swap @obsolete @chown @privileged @resources @pkey @setuid @timer AppArmorProfile=ae-slapd
[Install] WantedBy=multi-user.target
On 10/20/21 09:31, Ulrich Windl wrote:
Wondering about "LimitNOFILE=96": Wouldn't that limit the open sockets (connections) as well?
Sorry, I fetched the example from a memory-constrained demo server on which I deliberately configured really low resource usage values to provoke hitting limits.
(IIRC slapd pre-allocates a struct for the possible number of files.)
The default in Æ-DIR's ansible role is higher. Of course I expect the reader here to not blindly copy everything and rather check the exact meaning of systemd directives.
systemd has fairly good docs and I mainly wanted to point out the sandboxing stuff:
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Sandboxin...
Ciao, Michael.
On 19Oct21 18:17+0200, Michael Ströder wrote:
On 10/19/21 17:10, Quanah Gibson-Mount wrote:
--On Tuesday, October 19, 2021 1:00 AM -0700 "Paul B. Henson" henson@acm.org wrote:
I'm testing openldap 2.5 in preparation for migration my production services, and I noticed that the 2.5 RPMs no longer create an ldap user and instead run slapd as root by default?
If you want it to run as a non-root user, it's on you to configure it as such, including said user. The majority of Symas customers run as root.
IMHO there's no good reason to let systemd start slapd as root.
+1
Binding to so-called "privileged ports" can be achieved by setting these options in the systemd unit:
Alternatively, the old way, slapd still supports -u/-g options.
Find below ae-slapd.service generated by Æ-DIR's ansible role.
Thanks. This is interesting. Just some comments inline:
[Unit] Description=AE-DIR OpenLDAP server Requires=local-fs.target network.target After=local-fs.target network.target
[Service] Type=simple Environment=LD_PRELOAD=/usr/lib64/libtcmalloc.so.4 Environment=LDAPNOINIT=1 PIDFile=/run/ae-dir/slapd/slapd.pid
still need a pidfile?
ExecStart=/usr/lib64/slapd -d none -n ae-slapd -l LOCAL4 -s 7 -f /opt/ae-dir/etc/openldap/slapd.conf -h 'ldapi://%%2Frun%%2Fae-dir%%2Fslapd%%2Fldapi/????x-mod=0777 ldap://*:389 ldaps://*:636' -o slp=off
listening plaintext on all interfaces might be discouraged.
WorkingDirectory=/run/ae-dir/slapd User=ae-dir-slapd Group=ae-dir-slapd CapabilityBoundingSet=CAP_NET_BIND_SERVICE AmbientCapabilities=CAP_NET_BIND_SERVICE
This is nice, I think about to adopt that and abandon -u/-g
LimitNOFILE=96
this could be too low, depending on use case. it limits nr of incoming connections.
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX # various hardening options from ansible var aedir_systemd_hardening
[...]
Cheers,
On 10/20/21 09:43, Bastian Tweddell wrote:
On 19Oct21 18:17+0200, Michael Ströder wrote:
Find below ae-slapd.service generated by Æ-DIR's ansible role.
PIDFile=/run/ae-dir/slapd/slapd.pid
still need a pidfile?
Probably not.
(I'm also following the current discussion on systemd-devel list.)
ExecStart=/usr/lib64/slapd -d none -n ae-slapd -l LOCAL4 -s 7 -f /opt/ae-dir/etc/openldap/slapd.conf -h 'ldapi://%%2Frun%%2Fae-dir%%2Fslapd%%2Fldapi/????x-mod=0777 ldap://*:389 ldaps://*:636' -o slp=off
listening plaintext on all interfaces might be discouraged.
But using StartTLS has to be possible. Æ-DIR does not allow any clear-text connections because slapd.conf contains:
security ssf=128
LimitNOFILE=96
this could be too low, depending on use case. it limits nr of incoming connections.
Yes, a deliberately slow test value, see my other answer.
Ciao, Michael.
On 10/19/2021 8:10 AM, Quanah Gibson-Mount wrote:
If you want it to run as a non-root user, it's on you to configure it as such, including said user. The majority of Symas customers run as root. So yes, this is intentional and due to the fact that it's not attempting to be the replacement of the system bundled OpenLDAP. You're free to run things as best fits your environment.
Oh, ok; it was just an unexpected difference from the previous version that surprised me. Easy enough to resolve, although it seems inadvisable for the majority of your customers to run the service as root 8-/. How many do that intentionally, and how many do that because they just don't know any better and it's the default :)?
Thanks…
--On Tuesday, October 19, 2021 9:55 PM -0700 "Paul B. Henson" henson@acm.org wrote:
On 10/19/2021 8:10 AM, Quanah Gibson-Mount wrote:
If you want it to run as a non-root user, it's on you to configure it as such, including said user. The majority of Symas customers run as root. So yes, this is intentional and due to the fact that it's not attempting to be the replacement of the system bundled OpenLDAP. You're free to run things as best fits your environment.
Oh, ok; it was just an unexpected difference from the previous version that surprised me. Easy enough to resolve, although it seems inadvisable for the majority of your customers to run the service as root 8-/. How many do that intentionally, and how many do that because they just don't know any better and it's the default :)?
We advise them of best practices, but how they want to deploy is their decision.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org
-
Bastian Tweddell -
Michael Ströder -
Paul B. Henson -
Quanah Gibson-Mount -
Ulrich Windl