[RFC PATCH] specs: update message dictionary with source column

[Richard Guy Briggs]

On 2017-07-24 11:52, Steve Grubb wrote:
> On Monday, July 24, 2017 10:40:08 AM EDT Richard Guy Briggs wrote:
> > Add a column to indicate the source of the message, including indicating
> > whether or not it is related to syscalls.
> > 
> > Column name: SOURCE
> > Key:
> >         CTL     Control messages, usually initiated by audit daemon.
> 
> Most of these come from auditctl. Auditd only sends enable and setpid.

I had considered auditctl as part of the audit daemon, as opposed to
pam, systemd, vsftpd et al that supply user event messages, though I
suppose even systemd wants to play audit controller too.  I consider
AUDIT_EOE a control message even though it isn't in the 1000-block,
speaking of which I'd also added the list of message type ranges:
	https://github.com/linux-audit/audit-documentation/blob/master/specs/messages/message-dictionary-ranges.txt.

> >         DEP     Deprecated message types
> >         IND     Independent kernel message
> >         USR     User message
> >         SC      System-call related kernel message
> 
> I think that doing it like this is conflating 2 ideas: origin and class. 
> Origin is user space or kernel. The record class is ctl, dep, simple, and 
> compound events. There are some cases where things could be user space and 
> deprecated, or kernel and deprecated. And by its nature, all user space 
> originating records are simple.

It makes sense to talk of *records* as originating from kernel or
userspace, but this list also includes all message types including
control messages that may initiate in userspace, but trigger a reply of
the same message type from the kernel.

Thank you for acknowledging the assertion from another channel that all
user space records are simple.

At this point, I don't think we care about the origin of deprecated
messages, so it isn't worth complicating our nomenclature for this one
case, and that can be addressed with uDEP and kDEP or somesuch.

Can you name any compound events that are not related to a system call?
I chose the label "SC" to denote either the syscall record itself or
any of its auxilliary records.  I've also been trying to understand and
clean up any records that are used as auxilliary records so that they do
not appear as standalone records (such as ghak25/ghak35).

> To me, there are overlaps in the meaning. If they were split, this would make 
> subsetting easier. For example, I can do a join of this csv file and the audit 
> logs in csv to create an enhanced dataframe. Then I can subset on user 
> records.

I'm not totally opposed to separating the two columns, but would like a
reasonable justification for doing so to avoid needlessly cluttering the
document.

> -Steve

- RGB

--
Richard Guy Briggs <rgb at redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635