From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: [RFC PATCH] specs: update message dictionary with source column Date: Wed, 26 Jul 2017 23:08:08 -0400 Message-ID: <2602136.zviYMK8XDS@x2> References: <1500907208-10711-1-git-send-email-rgb@redhat.com> <20170726025142.GX17720@madcap2.tricolour.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Paul Moore Cc: Richard Guy Briggs , linux-audit@redhat.com List-Id: linux-audit@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 wrote: > > On 2017-07-25 14:14, Paul Moore wrote: > >> On Mon, Jul 24, 2017 at 11:48 PM, Richard Guy Briggs 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