linux-kernel - Re: [PATCH v1] audit: Improve path logging for unlinked files

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: <CABfwK109-4zzBUiQRdNg1re0dQ+dRdau=OXNFhtNsUc6YAEyBA@mail.gmail.com>
Date: Tue, 28 Oct 2025 18:22:42 -0700
From: Isaac Manjarres <isaacmanjarres@...gle.com>
To: Paul Moore <paul@...l-moore.com>
Cc: Eric Paris <eparis@...hat.com>, surenb@...gle.com, aliceryhl@...gle.com, 
	tweek@...gle.com, kernel-team@...roid.com, audit@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] audit: Improve path logging for unlinked files

On Tue, Oct 28, 2025 at 6:09 PM Paul Moore <paul@...l-moore.com> wrote:
>
> On Tue, Oct 28, 2025 at 8:54 PM Isaac J. Manjarres
> <isaacmanjarres@...gle.com> wrote:
> >
> > When logging the path associated with a denial, the path is scanned
> > to ensure that it does not contain control characters, unprintable
> > characters, double quote marks, or spaces. If it does, the hexadecimal
> > representation of the path is emitted.
> >
> > This can make debugging difficult in scenarios where the file name that
> > was given to the file does not contain any of those characters,
> > but the hexadecimal representation of the path is still emitted when a
> > denial occurs because the file is unlinked.
> >
> > For example, suppose a memfd is created with the name "MemoryHeapBase".
> > Memfds are unlinked, so when a denial related to that memfd is
> > encountered, and the the path name for it is obtained via d_path(), the
> > name will be: "/memfd:MemoryHeapBase (deleted)". Since the name has a
> > space, the audit logic will just print the hexadecimal representation
> > instead of the name:
> >
> > type=1400 audit(0.0:319): avc:  denied  { read write } for
> > path=2F6D656D66643A4D656D6F72794865617042617365202864656C6574656429
> > dev="tmpfs" ino=75 scontext=u:r:audioserver:s0
> > tcontext=u:object_r:system_server:s0 tclass=memfd_file permissive=0
> >
> > To improve debuggability of denials related to unlinked files, check
> > if the " (deleted)" suffix is detected in a path name and remove it
> > if so. This allows the actual filename to be validated and emitted
> > if appropriate, making denials easier to read and more actionable:
> >
> > type=1400 audit(0.0:254): avc:  denied  { read write } for
> > path="/memfd:MemoryHeapBase" dev="tmpfs" ino=67
> > scontext=u:r:audioserver:s0 tcontext=u:object_r:system_server:s0
> > tclass=memfd_file permissive=0
> >
> > Signed-off-by: Isaac J. Manjarres <isaacmanjarres@...gle.com>
> > ---
> >  kernel/audit.c | 16 ++++++++++++++--
> >  1 file changed, 14 insertions(+), 2 deletions(-)
>
> I'd prefer not to add any additional string processing to the audit hot path.

Hi Paul,

Thank you for taking the time to look through the patch. Would it help
if I could
optimize the logic to scan for the " (deleted)" string from the end of
the string
so that the search is bounded by at most 10 characters? I can also switch to
calling audit_log_n_untrustedstring() instead to avoid another call to strlen().

If not, do you have any other suggestions to help make this improvement?

Thanks,
Isaac