On Fri, Feb 16, 2018 at 3:23 AM, Richard Guy Briggs <rgb(a)redhat.com> wrote:
On 2018-02-15 17:15, Paul Moore wrote:
> On Mon, Feb 12, 2018 at 12:02 AM, Richard Guy Briggs <rgb(a)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