Previously, we saw O_PATH fds only when mediating fd inheritance on exec,
but because they would have no request associated with them, we would
unconditionally let them be inherited. Until we have better handling of
O_PATH fds, preserve the existing behavior of unconditionally allowing
them.
Signed-off-by: Ryan Lee <ryan.lee@xxxxxxxxxxxxx>
---
security/apparmor/lsm.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 11ace667cbbf..2349a1dd41f4 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -647,6 +647,16 @@ static int apparmor_file_open(struct file *file)
return 0;
}
+ /*
+ * Preserve the behavior of O_PATH fd creation not being mediated.
+ *
+ * TODO: we weren't handling O_PATH fds in aa_inherit_files anyways
+ * (all-zero request -> fds unconditionally inherited), so proper
+ * mediation of those will require changes in multiple places.
+ */
+ if (file->f_flags & O_PATH)
+ return 0;
+
label = aa_get_newest_cred_label_condref(file->f_cred, &needput);
if (!unconfined(label)) {
struct mnt_idmap *idmap = file_mnt_idmap(file);
--
2.43.0
base-kernel: v6.14-rc6
