https://bugs.openldap.org/show_bug.cgi?id=10605

Issue ID: 10605 Summary: slapo-auditlog creates the log file with insecure permissions (0666) Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs@openldap.org Reporter: dns.spiros@gmail.com Target Milestone: ---

Created attachment 1216 --> https://bugs.openldap.org/attachment.cgi?id=1216&action=edit patch implementing the described change

The auditlog overlay opens its log file with mode 0666:

fd = open(ad->ad_logfile, flags, 0666);

Combined with a typical process umask (e.g. 022), this commonly results in a file that is world-readable (0644) - and, with a permissive umask, can remain world-writable as literally requested.

This is a real concern for two independent reasons:

1. Confidentiality: the audit log records the full LDIF of every Add/ Modify/Delete/ModRDN operation, including attribute values. In our own testing, this included userPassword hashes (SSHA) appearing in clear LDIF form inside the log file. A world-readable audit log exposes this to any local user, regardless of the LDAP-level ACLs protecting the same data inside the directory itself.

2. Integrity: mode 0666 as requested permits world-write. An audit trail that any local user can modify does not reliably serve its purpose - tampering or truncation by an unprivileged user should not be possible.

Standard security guidance for audit logging (CIS Benchmarks, DISA STIG, PCI-DSS Requirement 10.5, ISO/IEC 27001 Annex A.12.4) consistently requires that audit logs be protected from unauthorized read and write access - not left to whatever the deploying administrator's umask happens to be.

Attached is a patch (plain git diff) changing the requested mode to 0640 (owner read/write, group read, no access for others), hardcoded rather than left to umask, consistent with how other security-sensitive files (e.g. private keys) are typically created.

Note: this is a behavior change for any existing deployment relying on broader access to the raw log file (e.g. a non-group member reading it directly) - such setups would need to adjust group membership or ACLs accordingly after upgrading.