From: Paul Moore <paul@paul-moore.com>
To: linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-unionfs@vger.kernel.org,
linux-erofs@lists.ozlabs.org
Cc: Amir Goldstein <amir73il@gmail.com>, Gao Xiang <xiang@kernel.org>
Subject: [PATCH 0/3] Fix incorrect overlayfs mmap() and mprotect() LSM access controls
Date: Mon, 16 Mar 2026 17:35:55 -0400 [thread overview]
Message-ID: <20260316213606.374109-5-paul@paul-moore.com> (raw)
The existing mmap() and mprotect() LSM access control points for the
overlayfs filesystem are incomplete in that they do not cover both the
user and backing files. This patchset corrects this through the addition
of a new backing file specific LSM hook, security_mmap_backing_file(),
a new user path file associated with a backing file that can be used by
LSMs in the security_file_mprotect() code path, and the associated
SELinux code changes.
The security_mmap_backing_file() hook is intended to allow LSMs to apply
access controls on mmap() operations accessing a backing file, similar to
the security_mmap_file() for user files. Due to the details around the
accesses and the desire to distinguish between the two types of accesses,
a new LSM hook was needed. More information on this new hook can be
found in the associated patch.
The new user path file replaces the existing user path stored in the
backing file. This change was necessary to support LSM based access
controls in the mprotect() code path where only one file is accessible
via the vma->vm_file field. Unfortunately, storing a reference to the
user file inside the backing file does not work due to the cyclic
ref counting so a stand-in was necessary, the new user O_PATH file.
This new O_PATH file is intended to be representative of the original
user file and can be used by LSMs to make access control decisions based
on both the backing and user files.
The SELinux changes in this patchset involve making use of the new
security_mmap_backing_file() hook and updating the existing mprotect()
access controls to take into account both the backing and user files.
These changes preserve the existing SELinux approach of allowing access
on overlayfs files if the current task has the necessary rights to the
user file and the mounting process has the necessary rights to the
underlying backing file.
--
Amir Goldstein (1):
backing_file: store user_path_file
Paul Moore (2):
lsm: add the security_mmap_backing_file() hook
selinux: fix overlayfs mmap() and mprotect() access checks
fs/backing-file.c | 28 +++++---
fs/erofs/ishare.c | 12 ++-
fs/file_table.c | 53 +++++++++++++---
fs/fuse/passthrough.c | 3
fs/internal.h | 5 -
fs/overlayfs/dir.c | 3
fs/overlayfs/file.c | 1
include/linux/backing-file.h | 29 ++++++++-
include/linux/file_ref.h | 10 ---
include/linux/lsm_audit.h | 2
include/linux/lsm_hook_defs.h | 2
include/linux/security.h | 10 +++
security/security.c | 25 +++++++
security/selinux/hooks.c | 108 ++++++++++++++++++++++++++++------
14 files changed, 231 insertions(+), 60 deletions(-)
next reply other threads:[~2026-03-16 21:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-16 21:35 Paul Moore [this message]
2026-03-16 21:35 ` [PATCH 1/3] backing_file: store user_path_file Paul Moore
2026-03-18 10:56 ` Christian Brauner
2026-03-18 12:06 ` Amir Goldstein
2026-03-18 20:00 ` Paul Moore
2026-03-16 21:35 ` [PATCH 2/3] lsm: add the security_mmap_backing_file() hook Paul Moore
2026-03-17 22:42 ` Paul Moore
2026-03-16 21:35 ` [PATCH 3/3] selinux: fix overlayfs mmap() and mprotect() access checks Paul Moore
2026-03-16 21:59 ` [PATCH 0/3] Fix incorrect overlayfs mmap() and mprotect() LSM access controls Paul Moore
2026-03-17 7:25 ` Amir Goldstein
2026-03-17 18:16 ` 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=20260316213606.374109-5-paul@paul-moore.com \
--to=paul@paul-moore.com \
--cc=amir73il@gmail.com \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=selinux@vger.kernel.org \
--cc=xiang@kernel.org \
/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