Hi All, I noticed the audit logs capture all details about any change in the directory, including password hashes when an account's password is updated. This strikes me as a security risk and I'd like to stop password hashes from being logged, or at least have them masked.
In reading https://www.port389.org/docs/389ds/design/audit-log-entry-attrs-design.html I see it might be possible to configure attributes to omit from the audit log by setting: cn=config nsslapd-auditlog-display-attrs: [ATTR ATTR ATTR] | * My reading of that is that you need to either allow all ("*"), or enumerate each and every attribute you want in the audit log; you can't say "all, except userPassword". Would that be correct? The problem with this is that every time we update the schema to add a new attribute type, we'll need to remember to update this list on every machine we capture audit logs on.
Is there perhaps some other way that I may have missed in my research? Thanks everyone, Trevor
On 5/31/24 11:26 AM, Trevor Fong wrote:
Hi All, I noticed the audit logs capture all details about any change in the directory, including password hashes when an account's password is updated. This strikes me as a security risk and I'd like to stop password hashes from being logged, or at least have them masked.
In reading https://www.port389.org/docs/389ds/design/audit-log-entry-attrs-design.html I see it might be possible to configure attributes to omit from the audit log by setting: cn=config nsslapd-auditlog-display-attrs: [ATTR ATTR ATTR] | * My reading of that is that you need to either allow all ("*"), or enumerate each and every attribute you want in the audit log; you can't say "all, except userPassword". Would that be correct?
That feature is to include identifying attributes in the audit log entry. It does not control how/what updates are recorded in the log. So a little history. A customer was using really odd DN's for its entries and they wanted the "cn" attribute of that entry displayed under the DN so it would be easier to parse/process:
time: 2024823487454875 dn: z=2738478343,ou=people,dc=org result: 0 changetype: modify ...
With the displays attribute feature it now adds whatever attribute from that entry you want (e.g. cn):
time: 2024823487454875 dn: z=2738478343,ou=people,dc=org #cn: Mark Reynolds result: 0 changetype: modify ...
So this has nothing to do with what updates are recorded in the log, it only allows you to add more "identifying" attributes about the entry being updated.
Going back to what you want, hiding a hashed password update, that would require a new RFE, but I don't see it as a security issue as the log files have the same FS permissions as the database files. So if you have root access you can still get whatever info you want.
HTH, Mark
The problem with this is that every time we update the schema to add a new attribute type, we'll need to remember to update this list on every machine we capture audit logs on.
Is there perhaps some other way that I may have missed in my research? Thanks everyone, Trevor
-- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
389-users@lists.fedoraproject.org
-
Mark Reynolds -
Trevor Fong