kernel event fields

[Steve Grubb]

Changing topics because this is way beyond the patch

On Wednesday, October 29, 2014 05:38:18 PM Richard Guy Briggs wrote:
> On 14/10/22, Steve Grubb wrote:
> > On Tuesday, October 21, 2014 06:30:24 PM Paul Moore wrote:
> > > On Tuesday, October 21, 2014 03:56:10 PM Steve Grubb wrote:
> > > Before we go to much farther, I'd really like us to agree that ordering
> > > is  not important, can we do that?
> > 
> > Its kind of doubtful we can do anything like this quickly. Maybe over
> > time. But for entirely new events, we can create some canonical order and
> > use it.
> 
> Good.  Where do we start?  Alphabetical order seems like an obvious but
> not very useful order.

Correct. Its not useful.
 
> How about an order based on classes of fields and importance or length
> of data within them?

That is roughly how all events work.

> Within each of those, have a standard order.
> Can that go in the "Audit Event Parsing Library Specifications"?

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