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).
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 <rgb(a)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