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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEjxPJ5BWjvDmQ37PPLHrmcTwRnOy6eW_uNoKG=ERZqRMAc3dw@mail.gmail.com>
Date: Wed, 22 Oct 2025 08:29:38 -0400
From: Stephen Smalley <stephen.smalley.work@...il.com>
To: Ondrej Mosnacek <omosnace@...hat.com>
Cc: xion.wang@...iatek.com, Paul Moore <paul@...l-moore.com>, 
	Matthias Brugger <matthias.bgg@...il.com>, 
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, wsd_upstream@...iatek.com, 
	huadian.liu@...iatek.com, linux-kernel@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH 0/1] selinux: export current_sid API for use in other
 kernel modules

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).