linux-kernel - Re: [GIT PULL] selinux/selinux-pr-20250323

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: <CAHk-=wiBH8FBL+pnXui8O-FSdyoG-yX81mUF9bsZcC6rR5ZtgQ@mail.gmail.com>
Date: Wed, 26 Mar 2025 18:20:41 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Thiébaud Weksteen <tweek@...gle.com>
Cc: Paul Moore <paul@...l-moore.com>, "Cameron K. Williams" <ckwilliams.work@...il.com>, 
	"Kipp N. Davis" <kippndavis.work@....com>, Stephen Smalley <stephen.smalley.work@...il.com>, 
	selinux@...r.kernel.org, linux-security-module@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Nick Kralevich <nnk@...gle.com>
Subject: Re: [GIT PULL] selinux/selinux-pr-20250323

On Wed, 26 Mar 2025 at 18:06, Thiébaud Weksteen <tweek@...gle.com> wrote:
>
> Taking one example from this merge request: kexec image loading.

So this is the kind of "why" I was looking for.

> Currently, any process which has CAP_SYS_BOOT can use kexec to replace
> the existing kernel. Android has 5 processes with CAP_SYS_BOOT, only 1
> of which needs kexec functionality [1]. By using these new
> permissions, we will ensure that this process is able to call kexec,
> while prohibiting other processes. SELinux provides us strong, kernel
> enforced guarantees which can be checked at policy compile time.
> Extending on this, we will use this patchset to guarantee that kernels
> and ramdisks executed by kexec come from known, good sources.
>
> The other hooks are of similar value to Android.

Now explain to me how the firmware loading hook works, not some
hand-wavy "similar value" thing.

Because it seems entirely bogus. Exactly because the context of
firmware loading is *not* something you can depend on. There is no
"one special process" that has firmware loading capabilities.

I'm looking at selinux_kernel_load_data() in particular, where you
don't even pass it a file at all, so it's not like it could check for
"is this file integrity-protected" or anything like that. It seems to
literally say "can this process load firmware", and as I've explained,
the firmware loading is done by random processes.

               Linus