On Wed, Jul 26, 2017 at 11:08 PM, Steve Grubb <[email protected]> wrote: > 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 <[email protected]> wrote: >> > On 2017-07-25 14:14, Paul Moore wrote: >> >> On Mon, Jul 24, 2017 at 11:48 PM, Richard Guy Briggs <[email protected]> > 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.
I agree that origination/source is important, see my comments above. I'm less convinced about differentiating between records that are attached to a syscall event, and those that happen independent of syscalls. >> 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. Regardless of what triggers the event, if the audit record is *created* by the kernel, I would consider the kernel to be the source. -- paul moore www.paul-moore.com -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
