[PATCH] selinux: reject writable opens of status file, drop mmap write checks

[PATCH] selinux: reject writable opens of status file, drop mmap write checks

[Stephen Smalley]

Similar to what
https://lore.kernel.org/selinux/aqPUqU3eZeFrykj3@gremlin/ does for the
policy file, update the .open handler for the status file to reject
writable opens, and update the .mmap handler to stop clearing
VM_MAYWRITE and checking for VM_WRITE. As a side effect, I believe
this will also prevent the issue previously reported with libselinux
users like systemd seg-faulting on the mmap'd status file if it is
truncated.

Link: https://lore.kernel.org/selinux/aqPUqU3eZeFrykj3@gremlin/
Link: https://lore.kernel.org/selinux/CAJ2a_Df6GOirF8TnNWTqNMpdWLHgjT9_v7G-PiL4e7LU2nr1PA@mail.gmail.com/
cc: ljs@kernel.org
cc: jannh@google.com
cc: jack@suse.cz
cc: cgzones@googlemail.com
cc: brauner@kernel.org
Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>
---
 security/selinux/selinuxfs.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index 292302eb60f3..3657778de82d 100644
--- a/security/selinux/selinuxfs.c
+++ b/security/selinux/selinuxfs.c
@@ -219,6 +219,9 @@ static int sel_open_handle_status(struct inode *inode, struct file *filp)
 	if (!status)
 		return -ENOMEM;
 
+	if (filp->f_mode & FMODE_WRITE)
+		return -EACCES;
+
 	filp->private_data = status;
 
 	return 0;
@@ -247,11 +250,6 @@ static int sel_mmap_handle_status(struct file *filp,
 	/* only allows one page from the head */
 	if (vma->vm_pgoff > 0 || size != PAGE_SIZE)
 		return -EIO;
-	/* disallow writable mapping */
-	if (vma->vm_flags & VM_WRITE)
-		return -EPERM;
-	/* disallow mprotect() turns it into writable */
-	vm_flags_clear(vma, VM_MAYWRITE);
 
 	return remap_pfn_range(vma, vma->vm_start,
 			       page_to_pfn(status),
-- 
2.55.0

Re: [PATCH] selinux: reject writable opens of status file, drop mmap write checks

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The patch fails to fully prevent truncation of the SELinux status file, leaving it vulnerable to path-based `truncate()` and `open(O_RDONLY | O_TRUNC)`.
--

commit 4651117ec33990214895f2560efc1a4e7aea0f83
Author: Stephen Smalley <stephen.smalley.work@gmail.com>

selinux: reject writable opens of status file, drop mmap write checks

This commit updates the .open handler for the SELinux status file to reject
writable opens, while removing mmap write checks. The stated goal is to
prevent userspace tools like systemd from segfaulting when the mmap'd status
file is truncated.

Link: https://lore.kernel.org/selinux/aqPUqU3eZeFrykj3@gremlin/
Link: https://lore.kernel.org/selinux/CAJ2a_Df6GOirF8TnNWTqNMpdWLHgjT9_v7G-PiL4e7LU2nr1PA@mail.gmail.com/

> diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
> index 5aaaf69410bb0..c787e2204717f 100644
> --- a/security/selinux/selinuxfs.c
> +++ b/security/selinux/selinuxfs.c
> @@ -219,6 +219,9 @@ static int sel_open_handle_status(struct inode *inode, struct file *filp)
>  	if (!status)
>  		return -ENOMEM;
>  
> +	if (filp->f_mode & FMODE_WRITE)
> +		return -EACCES;
> +

[Severity: High]
This is a pre-existing issue, but it looks like this might be an incomplete
fix for the truncation problem. Does this check fully prevent truncation of
the SELinux status file?

Because open(O_RDONLY | O_TRUNC) only sets FMODE_READ (and not FMODE_WRITE),
it bypasses this check in sel_open_handle_status() while still triggering
VFS truncation.

Additionally, a privileged process can invoke the path-based truncate()
syscall, which bypasses the .open() handler completely and falls back to
simple_setattr() to truncate the pagecache.

Since the goal of this patch is to prevent truncation to stop libselinux
users like systemd from segfaulting, it seems both of these paths still
allow the file to be truncated and trigger the crash.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260911135147.15355-1-stephen.smalley.work@gmail.com?part=1