[EXT] Re: The format of password change audit events seems to have changed, Can you confirm the correct record type ?

Wieprecht, Karen M. Karen.Wieprecht at jhuapl.edu
Fri Jul 9 14:22:18 UTC 2021


Warren,  I missed this part of your message.

>> This is an interesting topic.
>> Please, can you tell me what audit rule you are using that generates such records about root's (or any other account's) password change?

I double checked the rules on a different RHEL 7.9 system ,  and it looks like we are only picking up password change attempts for accts in the user space, but not root, so if the password was changed directly from a root login rather than via sudo from another acct,   we probably won’t see some of the related audit records.

This is the rule I believe is picking up password change events:
 –a always,exit –F path=/usr/bin/passwd –F per=x –F auid>=1000 auid!=4294967295 –k privileged passwd


There are also a specific watches on /etc/shadow and gshadow:
                -w /etc/shadow –p wa –k identity

I just attempted , from a non-priv acct, to change the root passwd, and I see the following relevant audit records key-value pairs :

This shows I successfully ran the passwd command  and that the root acct was targeted ,
                type=PROCTITLE   ...  proctitle=passwd root   ...
                type=PATH             name=/usr/bin/passwd
                type=SYSCALL    ...  comm=passwd  exe=/usr/bin/passwd  success=yes     key=setuid

This shows that a password change was attempted and failed, but doesn’t seem to correctly indicate that the root acct was targeted (id=myusername, not root):
                Type=USER_CHAUTHOK auid=myusername msg=’op=attempted-to-change-password    id=myusername   exe=/usr/bin/passwd  res=failed

So... based on this,  unless the patch versions are a bit different between the two RHEL7.9 systems I’ve been looking at,  it looks like you are actually generating  a reasonable message when  a password change is attempted,  but we probably need  to make sure we are picking up all password changes, not just those in the user space.

I unfortunately don’t have permission to change the audit rules,  but will see if I can the SA to test this for me.   If you are able to test in your environment and can confirm my findings, that would be wonderful, but I think we probably found our smoking gun, LOL.

Thanks so much,
Karen Wiepecht
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20210709/bea382fc/attachment.htm>


More information about the Linux-audit mailing list