Let's start by looking at the rule that we created that will alert us whenever a change is made to the /etc/passwd file:

sudo auditctl -w /etc/passwd -p wa -k passwd_changes

Now, let's make a change to the file and look for the alert message. Rather than add another user, since I'm running out of cats whose names I can use, I'll just use the chfn utility to  add contact information to the comment field for Cleopatra's entry:

[donnie@localhost etc]$ sudo chfn cleopatra
Changing finger information for cleopatra.
Name []: Cleopatra Tabby Cat
Office []: Donnie's back yard
Office Phone []: 555-5555
Home Phone []: 555-5556

Finger information changed.
[donnie@localhost etc]

I'll now use ausearch to look for any audit messages that this event may have generated:

[donnie@localhost ~]$ sudo ausearch -i -k passwd_changes
----
type=CONFIG_CHANGE msg=audit(12/11/2017 13:06:20.665:11393) : auid=donnie ses=842 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op=add_rule key=passwd_changes li
st=exit res=yes
----
type=CONFIG_CHANGE msg=audit(12/11/2017 13:49:15.262:11511) : auid=donnie ses=842 op=updated_rules path=/etc/passwd key=passwd_changes list=exit res=yes
[donnie@localhost ~]$

Here's the breakdown:

• -i: This takes any numeric data and, whenever possible, converts it into text.  In this case, it takes user ID numbers and converts them to the actual username, which shows up here as auid=donnie. If I were to leave the -i out, the user information would instead show up as auid=1000, which is my user ID number.
• -k passwd_changes: This specifies the key, or the name, of the audit rule for which we want to see audit messages.

You can see that there are two parts to this output. The first part just shows when I created the audit rule, so we're not interested in that. In the second part, you can see when I triggered the rule, but it doesn't show how I triggered it. So, let's use aureport to see if it will give us a bit more of a clue:

[donnie@localhost ~]$ sudo aureport -i -k | grep 'passwd_changes'
1. 12/11/2017 13:06:20 passwd_changes yes ? donnie 11393
2. 12/11/2017 13:49:15 passwd_changes yes ? donnie 11511
3. 12/11/2017 13:49:15 passwd_changes yes /usr/bin/chfn donnie 11512
4. 12/11/2017 14:54:11 passwd_changes yes /usr/sbin/usermod donnie 11728
5. 12/11/2017 14:54:25 passwd_changes yes /usr/sbin/usermod donnie 11736
[donnie@localhost ~]$

What's curious is that with ausearch, you have to specify the name, or key, of the audit rule that interests you after the -k option. With aureport, the -k option means that you want to look at all log entries that have to do with all audit rule keys. To see log entries for a specific key, just pipe the output into grep.  The -i option does the same thing that it does for ausearch.

As you can see, aureport parses the cryptic language of the audit.log file into plain language that's easier to understand. I wasn't sure about what I had done to generate events 1 and 2, so I looked in the /var/log/secure file to see if I could find out. I saw these two entries for those times:

Dec 11 13:06:20 localhost sudo: donnie : TTY=pts/1 ; PWD=/home/donnie ; USER=root ; COMMAND=/sbin/auditctl -w /etc/passwd -p wa -k passwd_changes
. . .
. . .
Dec 11 13:49:24 localhost sudo: donnie : TTY=pts/1 ; PWD=/home/donnie ; USER=root ; COMMAND=/sbin/ausearch -i -k passwd_changes

So, event 1 was from when I initially created the audit rule, and event 2 happened when I did an ausearch operation. 

I must confess that the events in lines 4 and 5 are a bit of a mystery. Both were created when I invoked the usermod command, and both of them correlate to the secure log entries where I added Vicky and Cleopatra to the secretcats group:

Dec 11 14:54:11 localhost sudo:  donnie : TTY=pts/1 ; PWD=/home/donnie ; USER=root ; COMMAND=/sbin/usermod -a -G secretcats vicky
Dec 11 14:54:11 localhost usermod[14865]: add 'vicky' to group 'secretcats'
Dec 11 14:54:11 localhost usermod[14865]: add 'vicky' to shadow group 'secretcats'
Dec 11 14:54:25 localhost sudo:  donnie : TTY=pts/1 ; PWD=/home/donnie ; USER=root ; COMMAND=/sbin/usermod -a -G secretcats cleopatra
Dec 11 14:54:25 localhost usermod[14871]: add 'cleopatra' to group 'secretcats'
Dec 11 14:54:25 localhost usermod[14871]: add 'cleopatra' to shadow group 'secretcats'

The strange part about this is that adding a user to a secondary group doesn't modify the passwd file. So, I really don't know why the rule got triggered to create the events in lines 4 and 5.

This leaves us with the event in line 3, which is where I used chfn to actually modify the passwd file. Here's the secure log entry for that:

Dec 11 13:48:49 localhost sudo:  donnie : TTY=pts/1 ; PWD=/etc ; USER=root ; COMMAND=/bin/chfn cleopatra

So, out of all of these events, the one in line 3 is the only one where the /etc/passwd file actually got modified.