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). > 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? > paul moore - RGB -- Richard Guy Briggs <r...@redhat.com> Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635