From: "Isaac J. Manjarres" <isaacmanjarres@google.com>
To: Paul Moore <paul@paul-moore.com>, Eric Paris <eparis@redhat.com>
Cc: surenb@google.com, aliceryhl@google.com, tweek@google.com,
"Isaac J. Manjarres" <isaacmanjarres@google.com>,
kernel-team@android.com, audit@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH v1] audit: Improve path logging for unlinked files
Date: Tue, 28 Oct 2025 17:54:47 -0700 [thread overview]
Message-ID: <20251029005448.495880-1-isaacmanjarres@google.com> (raw)
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@google.com>
---
kernel/audit.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index 26a332ffb1b8..dcfa60e0277d 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -2184,7 +2184,7 @@ void audit_log_untrustedstring(struct audit_buffer *ab, const char *string)
void audit_log_d_path(struct audit_buffer *ab, const char *prefix,
const struct path *path)
{
- char *p, *pathname;
+ char *p, *pathname, *suffix;
if (prefix)
audit_log_format(ab, "%s", prefix);
@@ -2199,8 +2199,20 @@ void audit_log_d_path(struct audit_buffer *ab, const char *prefix,
if (IS_ERR(p)) { /* Should never happen since we send PATH_MAX */
/* FIXME: can we save some information here? */
audit_log_format(ab, "\"<too_long>\"");
- } else
+ } else {
+ /*
+ * Terminate the buffer where the " (deleted)" suffix starts so
+ * that audit_log_untrustedstring() emits the pathname,
+ * assuming it doesn't have other control characters or spaces.
+ */
+ suffix = strstr(p, " (deleted)");
+ /* Ensure the string ends with the " (deleted)" suffix. */
+ if (suffix &&
+ ((p + strlen(p) - strlen(" (deleted)")) == suffix))
+ *suffix = '\0';
+
audit_log_untrustedstring(ab, p);
+ }
kfree(pathname);
}
--
2.51.1.851.g4ebd6896fd-goog
next reply other threads:[~2025-10-29 0:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-29 0:54 Isaac J. Manjarres [this message]
2025-10-29 1:09 ` [PATCH v1] audit: Improve path logging for unlinked files Paul Moore
2025-10-29 1:22 ` Isaac Manjarres
2025-10-29 2:15 ` Paul Moore
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251029005448.495880-1-isaacmanjarres@google.com \
--to=isaacmanjarres@google.com \
--cc=aliceryhl@google.com \
--cc=audit@vger.kernel.org \
--cc=eparis@redhat.com \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=surenb@google.com \
--cc=tweek@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox