Auditing User Additions - Critical Oversight?

Blackwell, Joseph M Joseph.M.Blackwell at boeing.com
Tue Apr 5 21:48:01 UTC 2016


Steve / et all,

I am working on scripting a report that can be run to filter and display the audits on a weekly basis, and I am having issues pulling specific events that indicate when users are added through the User Manager GUI (GNOME 2.28.2). I have nispom.rules file running on kernel "2.6.32-220.el6.x86_64 (RHEL 6.2)". The following are the only events that show up in the audit.log for this activity.

type=USER_ACCT msg=audit(04/05/2016 14:21:42.854:36615) : user pid=15667 uid=root auid=root ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct=root exe=/usr/sbin/userhelper hostname=? addr=? terminal=? res=success'
----
type=USER_START msg=audit(04/05/2016 14:21:42.870:36616) : user pid=15667 uid=root auid=root ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct=root exe=/usr/sbin/userhelper hostname=? addr=? terminal=? res=success'

These events are followed by other SYSCALL events showing root writing to shadow, gshadow, and passwd, but no indication of the actual account that was created/modified. Unless I am not configured correctly, these seems like a critical oversight. Perhaps I am missing something?

I know that we can gather other events, such as when the useradd command is used, but there are many admins that prefer to use the GUI. I suppose I could copy the passwd file on a weekly basis and perform a diff, but it seems to me that this type of information should be baked in already, especially in cases where we are using indexers such as splunk.

-Joe Blackwell

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20160405/b9ded79f/attachment.htm>


More information about the Linux-audit mailing list