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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
--
Identity Management Development Team
--
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
