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

[Steve Grubb <sgrubb@redhat.com>]

On Wednesday, July 26, 2017 6:36:24 PM EDT Paul Moore wrote:
> On Tue, Jul 25, 2017 at 10:51 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > On 2017-07-25 14:14, Paul Moore wrote:
> >> On Mon, Jul 24, 2017 at 11:48 PM, Richard Guy Briggs <rgb@redhat.com> 
wrote:
> >> > 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 think trying to chase down which application is trying to manage the
> >> audit subsystem is a losing battle.  In fact, I honestly would
> >> probably shrink this "source" list down to just a few possible values:
> >> kernel, userspace, and control.  I'm not convinced that granularity
> >> below this level is particularly useful, and could be confusing.
> > 
> > So I'm guessing from this comment that you think one column is sufficient?
> 
> To specify the source, yes.  If you want to classify the messages that
> is best done in a second column, IMHO.
> 
> > I'd really like to further break "kernel" down into "syscall" and
> > "independent/autonomous".
> Two thoughts:
> 
> 1) Is this important?  I know this is front in your mind as you are
> dealing with issues around this at the moment, but outside of your
> recent experience I don't see a lot of value in this information, only
> overhead in keeping it updated/correct.

Origination information can be useful. I'd be happy to blog about it to show 
people how to use it.

> 2) Is this "source" information?  I would argue "no" as they all come
> from the kernel.  *If* you feel this is truly important (see thought
> #1) then I would rather see this in a separate column.

They really don't all come from the kernel. They are serialized by the kernel. 
They go through the kernel. But the kernel is not always the _observer_ of an 
action that needs reporting.

-Steve