Re: Clarification on kernel threads

[Stephen Smalley <stephen.smalley.work@gmail.com>]

On Sun, Sep 14, 2025 at 1:16 AM Rahul Sandhu <nvraxn@gmail.com> wrote:
>
> Hey,
>
> SELinux has the sid kernel, which when used e.g. as following:
> (sidcontext kernel (sys.id sys.role kernel.subj sys.lowlow))
>
> But what privilege level (ring) do kernel threads run in? I can't find
> much clarification, and if a kernel thread runs in ring 0, then SELinux
> isn't of much use at all then given that the thread has complete access
> to both the processor and memory no?

Prior to the introduction of the userspace_initial_context policy
capability (and still true unless it is enabled in your policy and a
separate context is defined for the init SID), the first userspace
task inherited the kernel SID and remained in it until it loads policy
and re-exec's /sbin/init or switches to the init context. The same is
true of usermode helpers. So restricting the kernel SID could be used
to control such tasks before they exec or switch to another context.

SELinux can't protect against errant behavior by actual kernel
threads, as you note, but labeling kernel threads can be used to
protect such threads from unintended accesses, e.g. to prevent them
from exec'ing a userspace program via the usual kernel functions for
execve which apply the SELinux checks, or from reading/writing
untrusted files via the usual kernel functions for reading/writing
which apply the SELinux checks. An actively malicious kernel thread
can obviously bypass those checks altogether (or change the policy to
allow them), but protecting kernel threads from untrusted executables
and files can be useful to defend their integrity.