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: <CAFqZXNuPqwfqA23LH8NOG6KM1Nb7WvW77wnpp-vZ5omU40j_qQ@mail.gmail.com>
Date: Wed, 22 Oct 2025 10:08:04 +0200
From: Ondrej Mosnacek <omosnace@...hat.com>
To: xion.wang@...iatek.com
Cc: Paul Moore <paul@...l-moore.com>, Stephen Smalley <stephen.smalley.work@...il.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 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;

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