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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <f85fc1bc2bc72d13dd45f97d3014bd307e481e31.camel@mediatek.com>
Date: Thu, 23 Oct 2025 01:39:26 +0000
From: Xion Wang (王鑫) <Xion.Wang@...iatek.com>
To: "omosnace@...hat.com" <omosnace@...hat.com>,
	"stephen.smalley.work@...il.com" <stephen.smalley.work@...il.com>
CC: "linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, wsd_upstream
	<wsd_upstream@...iatek.com>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>,
	Huadian Liu (刘华典) <huadian.liu@...iatek.com>,
	"paul@...l-moore.com" <paul@...l-moore.com>, "matthias.bgg@...il.com"
	<matthias.bgg@...il.com>, AngeloGioacchino Del Regno
	<angelogioacchino.delregno@...labora.com>
Subject: Re: [PATCH 0/1] selinux: export current_sid API for use in other
 kernel modules

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@...hat.com>
> wrote:
> > 
> > On Wed, Oct 22, 2025 at 9:43 AM <xion.wang@...iatek.com> wrote:
> > > 
> > > From: Xion Wang <xion.wang@...iatek.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.