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

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(a)redhat.com&gt; wrote: > > On 2017-07-25 14:14, Paul Moore wrote: > >> On Mon, Jul 24, 2017 at 11:48 PM, Richard Guy Briggs <rgb(a)redhat.com&gt; 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.