linux-kernel - Re: [PATCH ghak8 ALT4 V4 0/3] audit: show more information for entries with anonymous parents

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHC9VhRFKTPhQRjL5QhPiQPA7WfV+TsVLgoVptnhLggkfvu0Cg@mail.gmail.com>
Date:   Thu, 15 Feb 2018 17:15:05 -0500
From:   Paul Moore <paul@...l-moore.com>
To:     Richard Guy Briggs <rgb@...hat.com>
Cc:     Linux-Audit Mailing List <linux-audit@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Eric Paris <eparis@...hat.com>, Steve Grubb <sgrubb@...hat.com>
Subject: Re: [PATCH ghak8 ALT4 V4 0/3] audit: show more information for
 entries with anonymous parents

On Mon, Feb 12, 2018 at 12:02 AM, Richard Guy Briggs <rgb@...hat.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.

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.

-- 
paul moore
www.paul-moore.com