[389-users] Re: Password Hashes in Audit Log

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.org
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

--
Identity Management Development Team
--
_______________________________________________
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.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue