Hello experts,
can you please give me some hints about best practice to run the slapd service? Is it advantageous to run the slapd with it's own service user/group (e. g. ldap:ldap) or is it recommended to run slapd as root (as it seems to be default)? Can you tell me something about advantages/disadvantages of each configuration?
Thank you for your support,
Carsten
On 6/13/22 15:14, Carsten Jäckel wrote:
Is it advantageous to run the slapd with it's own service user/group (e. g. ldap:ldap) or is it recommended to run slapd as root (as it seems to be default)?
As with other service demons you should run it as non-root user.
Two options:
1. Use CLI args -u and -g when starting slapd as root to let it change user, see slapd(8).
2. Start slapd directly as non-privileged users. If it needs to bind on privileged port(s) (<1024) you have to give it the capability CAP_NET_BIND_SERVICE, see capabilities(7).
Furthermore on modern Linux systems you could use systemd sandboxing and SyscallFilter= (and set the capability above):
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Sandboxin...
As an example see systemd service unit of Æ-DIR's slapd service attached below.
Additionally you could use AppArmor or SELinux.
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-repo/master #-----------------------------------------------------------------------
[Unit] Description=AE-DIR OpenLDAP server Requires=local-fs.target network.target After=local-fs.target network.target Before=nss-user-lookup.target aehostd.service Wants=nss-user-lookup.target
[Service] Type=simple Environment=SASL_CONF_PATH=/opt/ae-dir/etc/openldap/sasl2.conf Environment=LDAPNOINIT=1 PIDFile=/run/ae-dir/slapd/slapd.pid ExecStart=/usr/lib64/slapd -d none -n ae-slapd -l LOCAL4 -s 6 -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 ReadWritePaths=/run/ae-dir/slapd /opt/ae-dir/slapd-db/accesslog /opt/ae-dir/slapd-db/um User=ae-dir-slapd Group=ae-dir-slapd CapabilityBoundingSet=CAP_NET_BIND_SERVICE AmbientCapabilities=CAP_NET_BIND_SERVICE LimitNOFILE=2048 RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX # various hardening options from ansible var aedir_systemd_hardening StandardInput=null UMask=0077 PrivateUsers=no PrivateTmp=yes PrivateDevices=yes ProtectSystem=strict 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 PrivateIPC=yes RemoveIPC=yes MemoryDenyWriteExecute=yes SystemCallFilter=~ @clock @cpu-emulation @debug @keyring @module @mount @raw-io @reboot @swap @obsolete splice @resources @chown @privileged @pkey @setuid @timer SystemCallLog=@clock @cpu-emulation @debug @keyring @module @mount @raw-io @reboot @swap @obsolete splice @resources @chown @privileged @pkey @setuid @timer AppArmorProfile=ae-slapd
[Install] WantedBy=multi-user.target
Carsten, As a best practice whenever possible services in general should be ran within the context of a user that has the least amount of privilege possible. In this case, it's entirely supported and straightforward to configure OpenLDAP to run as a non-privileged user and group and to further deploy additional hardening on the user object such as setting the shell for that user to /sbin/nologin, !! in /etc/shadow for the password field, etc. I.E. systemd has long supported running services as a non-root user and again so do modern versions of Symas OpenLDAP:
https://repo.symas.com/soldap/systemd/
In a sense I would think that most enterprises would need to justify as to why they wouldn't deploy OpenLDAP with the service configured to use a non-privileged account.
Best, Aaron
-----Original Message----- From: Carsten Jäckel carsten.jaeckel@tu-dortmund.de Sent: Monday, June 13, 2022 9:15 AM To: openldap-technical@openldap.org Subject: context of slapd service
Warning: This email is from outside the company. Be careful clicking links or attachments.
Hello experts,
can you please give me some hints about best practice to run the slapd service? Is it advantageous to run the slapd with it's own service user/group (e. g. ldap:ldap) or is it recommended to run slapd as root (as it seems to be default)? Can you tell me something about advantages/disadvantages of each configuration?
Thank you for your support,
Carsten
---------------------------------------------------------------------- The information contained in this message may be privileged, confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify your representative immediately and delete this message from your computer. Thank you.
"Bliss, Aaron" abliss1@paychex.com schrieb am 14.06.2022 um 17:03 in
Nachricht CH2PR02MB6216DEB37F4834391976FF52FCAA9@CH2PR02MB6216.namprd02.prod.outlook.com
Carsten, As a best practice whenever possible services in general should be ran within the context of a user that has the least amount of privilege
possible.
In this case, it's entirely supported and straightforward to configure OpenLDAP to run as a non-privileged user and group and to further deploy additional hardening on the user object such as setting the shell for that user to /sbin/nologin, !! in /etc/shadow for the password field, etc. I.E.
systemd has long supported running services as a non-root user and again so
do modern versions of Symas OpenLDAP:
https://repo.symas.com/soldap/systemd/
In a sense I would think that most enterprises would need to justify as to why they wouldn't deploy OpenLDAP with the service configured to use a non-privileged account.
Maybe I should mention one pitfall: When using slapadd to create databases, better ran it as the user than runs slapd; otherwise they are owned by root, most likely ;-)
Best, Aaron
-----Original Message----- From: Carsten Jäckel carsten.jaeckel@tu-dortmund.de Sent: Monday, June 13, 2022 9:15 AM To: openldap-technical@openldap.org Subject: context of slapd service
Warning: This email is from outside the company. Be careful clicking links or attachments.
Hello experts,
can you please give me some hints about best practice to run the slapd service? Is it advantageous to run the slapd with it's own service user/group (e. g.
ldap:ldap) or is it recommended to run slapd as root (as it seems to be default)? Can you tell me something about advantages/disadvantages of each configuration?
Thank you for your support,
Carsten
The information contained in this message may be privileged, confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this
message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify
your representative immediately and delete this message from your computer.
Thank you.
openldap-technical@openldap.org
-
Bliss, Aaron -
Carsten Jäckel -
Michael Ströder -
Ulrich Windl