On Fri, Feb 16, 2018 at 3:23 AM, Richard Guy Briggs <r...@redhat.com> wrote: > On 2018-02-15 17:15, Paul Moore wrote: >> On Mon, Feb 12, 2018 at 12:02 AM, Richard Guy Briggs <r...@redhat.com> wrote: >> > More than one filesystem was causing hundreds to thousands of null PATH >> > records to be associated with the *init_module SYSCALL records on a few >> > modules with corresponding audit syscall rules. >> > >> > This patchset adds extra information to those PATH records to provide >> > insight into what is generating them, including a partial pathname, >> > fstype field, and two new filetypes that indicate the pathname isn't >> > anchored at the root of the task's root filesystem. >> > >> > Richard Guy Briggs (3): >> > audit: show partial pathname for entries with anonymous parents >> > audit: append new fstype field for anonymous PATH records >> > audit: add new filetypes CREATE_ANON and PARENT_ANON >> >> The more I look at this, the more I prefer your original approach that >> prefixed the relative pathname with the fstype. Yes, I do realize >> that you sort of work around that by including the fstype as a new >> field in the PATH records, but we're still stuck with those odd >> relative/un-rooted name fields. > > They are signalled as being unrooted by the ANON filetypes. And now > that you mention it, should fail the ausearch-test since it isn't a "full > path", as claimed is necessary in ghak70 (so I don't see why the > KERN_MODULE name= record/field fails that test).
Yes. I still prefer your original approach. >> Further, I don't recall ever hearing a good reason why the original >> approach wasn't acceptable to Steve's userspace. I know he did make >> some very last minute hand-wavy comments, but none of those made any >> sense to me; I don't understand why Steve's audit record parser is >> even looking in the pathname string. >> >> I'm going to park these patches in limbo for the time being. > > Can you give me an idea how long that might be? If you need an answer right now, consider it to be "indefinitely". -- paul moore www.paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit