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

["Xion Wang (王鑫)" <Xion.Wang@mediatek.com>]

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.