Re: [PATCH ghak28 V4] audit: log audit netlink multicast bind and unbind events

From: Steve Grubb
Date: Thu Jan 23 2020 - 15:11:58 EST


On Thursday, January 23, 2020 11:13:49 AM EST Richard Guy Briggs wrote:
> Steve, can you say why this order should be the standard? From:
> http://people.redhat.com/sgrubb/audit/record-fields.html

The majority of events go down the path of:
pid,uid,auid,ses,subj,op,comm,exe,res

Which lands on the parse_user() function.

If for some reason we really wanted to stay on a "kernel" parser, then I'd
recommend:
auid,uid,ses,subj,pid,comm,exe,op,res

which lands on the parse_kernel_anom() function.

Either of those have complete information and requires no syscall record.

-Steve


> I get:
> SYSCALL/ANOM_LINK/FEATURE_CHANGE
> ppid pid auid uid gid euid suid
> fsuid egid sgid fsgid tty ses comm exe subj
> ANOM_ABEND/SECCOMP
> auid uid gid ses subj pid
> comm exe LOGIN
> pid uid subj old-auid auid tty
> old-ses ses SYSTEM_BOOT/SYSTEM_SHUTDOWN
> pid uid auid ses subj comm exe
> USER_LOGIN
> pid uid auid ses subj uid exe
> DAEMON_START
> auid pid uid ses subj
> DAEMON_CONFIG/DAEMON_END
> auid pid subj
> ANOM_PROMISCUOUS
> auid uid gid ses
> 52msgs
> pid uid auid ses subj *
> CONFIG_CHANGE
> auid ses subj
>
> This new record is:
> EVENT_LISTENER
> pid uid auid tty ses subj comm exe
>
> And using the search criteria following, I get no other matches:
> /pid.*uid.*auid.*tty.*ses.*subj.*comm.*exe
> so this appears to be a new field order.