What were you trying to do that didn't work?

Deploy 389 Directory Server with a hardened systemd service configuration. The shipped `dirsrv@.service` unit file is missing `NoNewPrivileges=yes` and `MemoryDenyWriteExecute=yes` despite the service running with a broad capability bounding set (`CAP_SETUID`, `CAP_SETGID`, `CAP_DAC_OVERRIDE`, `CAP_CHOWN`, `CAP_FOWNER`).

What is the impact of this issue to you?

A compromised `ns-slapd` process could potentially gain additional privileges via setuid binaries reachable within the service's execution context, as `NoNewPrivileges` is not set to constrain capability escalation. The absence of `MemoryDenyWriteExecute` leaves W+X memory available with no apparent functional justification — 389-ds does not use JIT compilation or dynamically generated code paths that require it.

The service has clearly had hardening work applied (`ProtectKernelTunables`, `ProtectKernelModules`, `ProtectControlGroups`, `ProtectClock`, `PrivateTmp`, `PrivateDevices` are all present), and the unit file already references the openSUSE systemd hardening effort in a comment. An upstream issue tracking this work (https://github.com/389ds/389-ds-base/issues/5018) was opened in 2021 but never resolved. This report is specific to the el10 package.

Please provide the package NVR for which the bug is seen:

389-ds-base-3.2.0-4.el10.x86_64

How reproducible is this bug?:

Always

Steps to reproduce

1. Download the package: dnf download 389-ds-base (or fetch the el10 RPM directly from Koji: curl -sLO "https://kojihub.stream.centos.org/kojifiles/packages/389-ds-base/3.2.0/4.el10/x86_64/389-ds-base-3.2.0-4.el10.x86_64.rpm")
2. Extract the unit file: `rpm2cpio 389-ds-base-3.2.0-4.el10.x86_64.rpm | cpio -i --to-stdout ./usr/lib/systemd/system/dirsrv@.service 2>/dev/null`
3. Check for the missing directives: `grep -E 'NoNewPrivileges|MemoryDenyWriteExecute' dirsrv@.service`

Expected results

Both `NoNewPrivileges=yes` and `MemoryDenyWriteExecute=yes` present in the `[Service]` section, consistent with the existing hardening directives and the openSUSE hardening effort already referenced in the unit file.

Actual results

Neither directive is present. The service runs with `CAP_SETUID`, `CAP_SETGID`, `CAP_DAC_OVERRIDE`, `CAP_CHOWN`, and `CAP_FOWNER` in the capability bounding set without `NoNewPrivileges` to prevent privilege escalation via setuid binaries.

*Suggested remediation*
Add to the `[Service]` section of `dirsrv@.service`:
```
NoNewPrivileges=yes
MemoryDenyWriteExecute=yes
```
Both should be tested against a running instance with LDAP plugins active before shipping. Note: `SystemCallFilter` is intentionally not requested — a directory server syscall profile requires careful testing to avoid service breakage.