Changing topics because this is way beyond the patch On Wednesday, October 29, 2014 05:38:18 PM Richard Guy Briggs wrote: Correct. Its not useful. That is roughly how all events work. You can sometimes have a standard order. Many times you cannot. The vast majority of events have a specific order. I decided to go look at all the kernel events to see exactly what is the problem. AUDIT_LOGIN - pid,uid,subj,old-auid,auid,old-ses,ses,res AUDIT_SYSCALL - arch,syscall,success,exit,a0,a1,a2,a3,items,ppid,pid,auid,uid,gid,euid,suid,fsuid,egid,sgid,fsgid,tty,ses,comm,exe,subj,key AUDIT_CONFIG_CHANGE - val,old,auid,ses,subj,res AUDIT_TTY - pid,uid,auid,ses,major,minor,comm,data, AUDIT_NETFILTER_PKT - action,hook,len,inif,outif,mark,smac,dmac,macproto,saddr,daddr,ipid,proto,frag,truncated,sport,dport AUDIT_NETFILTER_CFG -syscall record AUDIT_SECCOMP - auid,uid,gid,ses,subj,comm,exe,sig,arch,syscall,compat,ip,code AUDIT_FEATURE_CHANGE - ppid,pid,auid,uid,gid,euid,suid,fsuid,egid,sgid,fsgid,tty,ses,comm,exe,subj,feature,old,new,old_lock,new_lock,res AUDIT_SELINUX_ERR - deprecated AUDIT_AVC_PATH - deprecated AUDIT_MAC_POLICY_LOAD - syscall record AUDIT_MAC_STATUS - syscall record AUDIT_MAC_CONFIG_CHANGE - syscall record AUDIT_MAC_IPSEC_EVENT - deprecated AUDIT_ANOM_PROMISCUOUS - dev,prom,old_prom,auid,uid,gid,ses AUDIT_ANOM_ABEND - auid,uid,gid,ses,subj,pid,comm,reason AUDIT_ANOM_LINK - op,ppid,pid,auid,uid,gid,euid,suid,fsuid,egid,sgid,fsgid,tty,ses,comm,exe,subj,res + syscall & path records AUDIT_INTEGRITY_DATA - pid,uid,auid,ses,subj,op,cause,comm,name,dev,ino,res AUDIT_INTEGRITY_METADATA - pid,uid,auid,ses,subj,op,cause,comm,name,dev,ino,res AUDIT_INTEGRITY_STATUS - pid,uid,auid,ses,subj,op,cause,comm,name,dev,ino,res AUDIT_INTEGRITY_HASH - pid,uid,auid,ses,subj,op,cause,comm,name,dev,ino,res AUDIT_INTEGRITY_PCR - pid,uid,auid,ses,subj,op,cause,comm,name,dev,ino,res AUDIT_INTEGRITY_RULE - varies The main event that is kinda messed up is AUDIT_FEATURE_CHANGE. Because its so new, I doubt anyone is counting on it right now. All that group information should go away. ppid is not needed nor is suid and fsuid. The standard order seems to be pid,uid,auid,ses,subj sometimes comm,exe,tty and always ends with res. That said, looking at how few kernel events there really is, I don't really see much of a problem. The INTEGRITY events are all identical, the MAC events all are overkill because of the syscall record, ANOM events look fine as is, NETFILTER & SYSCALL are exactly right as is. That means we are really talking about LOGIN, CONFIG_CHANGE, TTY, and possibly FEATURE_CHANGE? Are we talking about other events not here? Also, adding a field is not as bad as deleting one or mixing them all around. For example, subj could be added at the end of ANOM_PROMISCUOUS and it wouldn't hurt anything. -Steve