security/selinux/hooks.c | 11 +++++++++++ security/selinux/include/objsec.h | 12 ++---------- 2 files changed, 13 insertions(+), 10 deletions(-)
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
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.
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).
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.
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.
© 2016 - 2026 Red Hat, Inc.