From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: kernel event fields Date: Thu, 30 Oct 2014 15:35:31 -0400 Message-ID: <2299007.1AIZU2xyH9@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from x2.localnet (vpn-235-106.phx2.redhat.com [10.3.235.106]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9UJZQGO010884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 30 Oct 2014 15:35:27 -0400 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com 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