[PATCH 0/1] selinux: export current_sid API for use in other kernel modules

[PATCH 0/1] selinux: export current_sid API for use in other kernel modules

[xion.wang]

From: Xion Wang <xion.wang@mediatek.com>

We have a kernel driver designed to monitor the status of the Android
userspace watchdog. The implementation works as follows: we modify the
Android userspace watchdog code to periodically send a "kick" signal to
the kernel driver via ioctl, so that the kernel driver can determine
whether the userspace is still responsive. If the kernel driver does not
receive a kick signal from the userspace watchdog within a certain
period, it infers that the userspace is stuck. In this case, the kernel
driver will dump key process information at the kernel level and trigger
a full system reboot.

To ensure that only the legitimate Android userspace watchdog process can
access the ioctl interface and perform the kick operation, and to prevent
malicious or unauthorized processes from spoofing the kick action (which
could compromise system reliability), we want to identify the calling
task by its security identifier (sid). By checking the sid, we can
effectively prevent unauthorized processes from sending kick signals.

Currently, the current_sid() function in the kernel is defined as
static inline and cannot be directly called from modules or drivers. We
propose to export this function, so that the kernel driver can call
current_sid() to obtain the sid of the current process and decide whether
to allow the kick operation.

This change will help enhance system security and robustness by
preventing the watchdog mechanism from being bypassed or abused.

I would like to ask the maintainers if there are any additional security
concerns regarding exporting current_sid() as a public API, or if there
are any alternative or more recommended approaches to achieve this goal.
Any feedback or suggestions would be greatly appreciated.

Xion Wang (1):
  selinux: export current_sid API for use in other kernel modules

 security/selinux/hooks.c          | 11 +++++++++++
 security/selinux/include/objsec.h | 12 ++----------
 2 files changed, 13 insertions(+), 10 deletions(-)

-- 
2.45.2

[PATCH 1/1] selinux: export current_sid API for use in other kernel modules

[xion.wang]

From: Xion Wang <xion.wang@mediatek.com>

Convert current_sid from static inline to a global
function and export it with EXPORT_SYMBOL.
This allows other kernel modules to retrieve
the SELinux security ID of the current task.

Signed-off-by: Xion Wang <xion.wang@mediatek.com>
---
 security/selinux/hooks.c          | 11 +++++++++++
 security/selinux/include/objsec.h | 12 ++----------
 2 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index dfc22da42f30..0c128f323332 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -229,6 +229,17 @@ static inline u32 cred_sid(const struct cred *cred)
 	return tsec->sid;
 }
 
+/*
+ * get the subjective security ID of the current task
+ */
+u32 current_sid(void)
+{
+	const struct task_security_struct *tsec = selinux_cred(current_cred());
+
+	return tsec->sid;
+}
+EXPORT_SYMBOL(current_sid);
+
 static void __ad_net_init(struct common_audit_data *ad,
 			  struct lsm_network_audit *net,
 			  int ifindex, struct sock *sk, u16 family)
diff --git a/security/selinux/include/objsec.h b/security/selinux/include/objsec.h
index 2d5139c6d45b..787a0cd74ff0 100644
--- a/security/selinux/include/objsec.h
+++ b/security/selinux/include/objsec.h
@@ -202,16 +202,6 @@ selinux_ipc(const struct kern_ipc_perm *ipc)
 	return ipc->security + selinux_blob_sizes.lbs_ipc;
 }
 
-/*
- * get the subjective security ID of the current task
- */
-static inline u32 current_sid(void)
-{
-	const struct task_security_struct *tsec = selinux_cred(current_cred());
-
-	return tsec->sid;
-}
-
 static inline struct superblock_security_struct *
 selinux_superblock(const struct super_block *superblock)
 {
@@ -265,4 +255,6 @@ selinux_bpf_token_security(struct bpf_token *token)
 	return token->security + selinux_blob_sizes.lbs_bpf_token;
 }
 #endif /* CONFIG_BPF_SYSCALL */
+
+u32 current_sid(void);
 #endif /* _SELINUX_OBJSEC_H_ */
-- 
2.45.2

Re: [PATCH 0/1] selinux: export current_sid API for use in other kernel modules

[Christoph Hellwig]

On Wed, Oct 22, 2025 at 03:27:17PM +0800, xion.wang@mediatek.com wrote:
> From: Xion Wang <xion.wang@mediatek.com>
> 
> We have a kernel driver designed to monitor the status of the Android
> userspace watchdog.

That module is not included in the patch series, making the export
directly unacceptable.

Re: [PATCH 0/1] selinux: export current_sid API for use in other kernel modules

[Ondrej Mosnacek]

On Wed, Oct 22, 2025 at 9:43 AM <xion.wang@mediatek.com> wrote:
>
> From: Xion Wang <xion.wang@mediatek.com>
>
> We have a kernel driver designed to monitor the status of the Android
> userspace watchdog. The implementation works as follows: we modify the
> Android userspace watchdog code to periodically send a "kick" signal to
> the kernel driver via ioctl, so that the kernel driver can determine
> whether the userspace is still responsive. If the kernel driver does not
> receive a kick signal from the userspace watchdog within a certain
> period, it infers that the userspace is stuck. In this case, the kernel
> driver will dump key process information at the kernel level and trigger
> a full system reboot.
>
> To ensure that only the legitimate Android userspace watchdog process can
> access the ioctl interface and perform the kick operation, and to prevent
> malicious or unauthorized processes from spoofing the kick action (which
> could compromise system reliability), we want to identify the calling
> task by its security identifier (sid). By checking the sid, we can
> effectively prevent unauthorized processes from sending kick signals.
>
> Currently, the current_sid() function in the kernel is defined as
> static inline and cannot be directly called from modules or drivers. We
> propose to export this function, so that the kernel driver can call
> current_sid() to obtain the sid of the current process and decide whether
> to allow the kick operation.
>
> This change will help enhance system security and robustness by
> preventing the watchdog mechanism from being bypassed or abused.
>
> I would like to ask the maintainers if there are any additional security
> concerns regarding exporting current_sid() as a public API, or if there
> are any alternative or more recommended approaches to achieve this goal.
> Any feedback or suggestions would be greatly appreciated.

Couldn't you just use security_cred_getsecid() or the new
security_cred_getlsmprop()?

Untested:

u32 sid;
security_cred_getsecid(current_cred(), &sid);

-- or --

lsm_prop prop;
security_cred_getlsmprop(current_cred(), &prop);
u32 sid = prop.selinux->secid;

-- 
Ondrej Mosnacek
Senior Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.

Re: [PATCH 0/1] selinux: export current_sid API for use in other kernel modules

[Stephen Smalley]

On Wed, Oct 22, 2025 at 4:08 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
>
> On Wed, Oct 22, 2025 at 9:43 AM <xion.wang@mediatek.com> wrote:
> >
> > From: Xion Wang <xion.wang@mediatek.com>
> >
> > We have a kernel driver designed to monitor the status of the Android
> > userspace watchdog. The implementation works as follows: we modify the
> > Android userspace watchdog code to periodically send a "kick" signal to
> > the kernel driver via ioctl, so that the kernel driver can determine
> > whether the userspace is still responsive. If the kernel driver does not
> > receive a kick signal from the userspace watchdog within a certain
> > period, it infers that the userspace is stuck. In this case, the kernel
> > driver will dump key process information at the kernel level and trigger
> > a full system reboot.
> >
> > To ensure that only the legitimate Android userspace watchdog process can
> > access the ioctl interface and perform the kick operation, and to prevent
> > malicious or unauthorized processes from spoofing the kick action (which
> > could compromise system reliability), we want to identify the calling
> > task by its security identifier (sid). By checking the sid, we can
> > effectively prevent unauthorized processes from sending kick signals.
> >
> > Currently, the current_sid() function in the kernel is defined as
> > static inline and cannot be directly called from modules or drivers. We
> > propose to export this function, so that the kernel driver can call
> > current_sid() to obtain the sid of the current process and decide whether
> > to allow the kick operation.
> >
> > This change will help enhance system security and robustness by
> > preventing the watchdog mechanism from being bypassed or abused.
> >
> > I would like to ask the maintainers if there are any additional security
> > concerns regarding exporting current_sid() as a public API, or if there
> > are any alternative or more recommended approaches to achieve this goal.
> > Any feedback or suggestions would be greatly appreciated.
>
> Couldn't you just use security_cred_getsecid() or the new
> security_cred_getlsmprop()?
>
> Untested:
>
> u32 sid;
> security_cred_getsecid(current_cred(), &sid);
>
> -- or --
>
> lsm_prop prop;
> security_cred_getlsmprop(current_cred(), &prop);
> u32 sid = prop.selinux->secid;
>

I suppose the next logical question would be what will you do with the
secid - you can't just compare it to a fixed value since they are
dynamically assigned.
Normally you would instead just pass it to a SELinux permission check
to see if that SID is allowed the permission required to perform this
operation.
But this too would require using a LSM hook to perform the permission
check (in which case you don't need to fetch the SID separately; it
can all be done within the same hook).

Re: [PATCH 0/1] selinux: export current_sid API for use in other kernel modules

[Xion Wang (王鑫)]

On Wed, 2025-10-22 at 08:29 -0400, Stephen Smalley wrote:
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> 
> 
> On Wed, Oct 22, 2025 at 4:08 AM Ondrej Mosnacek <omosnace@redhat.com>
> wrote:
> > 
> > On Wed, Oct 22, 2025 at 9:43 AM <xion.wang@mediatek.com> wrote:
> > > 
> > > From: Xion Wang <xion.wang@mediatek.com>
> > > 
> > > We have a kernel driver designed to monitor the status of the
> > > Android
> > > userspace watchdog. The implementation works as follows: we
> > > modify the
> > > Android userspace watchdog code to periodically send a "kick"
> > > signal to
> > > the kernel driver via ioctl, so that the kernel driver can
> > > determine
> > > whether the userspace is still responsive. If the kernel driver
> > > does not
> > > receive a kick signal from the userspace watchdog within a
> > > certain
> > > period, it infers that the userspace is stuck. In this case, the
> > > kernel
> > > driver will dump key process information at the kernel level and
> > > trigger
> > > a full system reboot.
> > > 
> > > To ensure that only the legitimate Android userspace watchdog
> > > process can
> > > access the ioctl interface and perform the kick operation, and to
> > > prevent
> > > malicious or unauthorized processes from spoofing the kick action
> > > (which
> > > could compromise system reliability), we want to identify the
> > > calling
> > > task by its security identifier (sid). By checking the sid, we
> > > can
> > > effectively prevent unauthorized processes from sending kick
> > > signals.
> > > 
> > > Currently, the current_sid() function in the kernel is defined as
> > > static inline and cannot be directly called from modules or
> > > drivers. We
> > > propose to export this function, so that the kernel driver can
> > > call
> > > current_sid() to obtain the sid of the current process and decide
> > > whether
> > > to allow the kick operation.
> > > 
> > > This change will help enhance system security and robustness by
> > > preventing the watchdog mechanism from being bypassed or abused.
> > > 
> > > I would like to ask the maintainers if there are any additional
> > > security
> > > concerns regarding exporting current_sid() as a public API, or if
> > > there
> > > are any alternative or more recommended approaches to achieve
> > > this goal.
> > > Any feedback or suggestions would be greatly appreciated.
> > 
> > Couldn't you just use security_cred_getsecid() or the new
> > security_cred_getlsmprop()?
> > 
> > Untested:
> > 
> > u32 sid;
> > security_cred_getsecid(current_cred(), &sid);
> > 
> > -- or --
> > 
> > lsm_prop prop;
> > security_cred_getlsmprop(current_cred(), &prop);
> > u32 sid = prop.selinux->secid;
> > 
> 
> I suppose the next logical question would be what will you do with
> the
> secid - you can't just compare it to a fixed value since they are
> dynamically assigned.
> Normally you would instead just pass it to a SELinux permission check
> to see if that SID is allowed the permission required to perform this
> operation.
> But this too would require using a LSM hook to perform the permission
> check (in which case you don't need to fetch the SID separately; it
> can all be done within the same hook).


The SID of a process corresponds to its SELinux label. By recording the
SID associated with a trusted SELinux label at boot time, we can later
check if other processes have the same SID before granting access to
sensitive driver nodes. Since the SID for a SELinux label remains
constant during a single boot, this approach ensures that only
processes with specific SELinux labels can access the node, even after
user-space restarts.


This API,
security_cred_getsecid(current_cred(), &sid);
can correctly obtain the SID of the current process in local testing.