tomoyo: allow building as a loadable LSM module
authorTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Mon, 23 Sep 2024 10:55:50 +0000 (19:55 +0900)
committerTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Tue, 24 Sep 2024 13:35:30 +0000 (22:35 +0900)
commit8b985bbfabbe46c8b9200d7d299030232c8ebd05
treeff6f0d52209b46772679e1401819aac29a06521f
parent268225a1de1a021bac4884e7d61fe047345cc9be
tomoyo: allow building as a loadable LSM module

One of concerns for enabling TOMOYO in prebuilt kernels is that distributor
wants to avoid bloating kernel packages. Although boot-time kernel command
line options allows selecting built-in LSMs to enable, file size increase
of vmlinux and memory footprint increase of vmlinux caused by builtin-but-
not-enabled LSMs remains. If it becomes possible to make LSMs dynamically
appendable after boot using loadable kernel modules, these problems will
go away.

Another of concerns for enabling TOMOYO in prebuilt kernels is that who can
provide support when distributor cannot provide support. Due to "those who
compiled kernel code is expected to provide support for that kernel code"
spell, TOMOYO is failing to get enabled in Fedora distribution [1]. The
point of loadable kernel module is to share the workload. If it becomes
possible to make LSMs dynamically appendable after boot using loadable
kernel modules, as with people can use device drivers not supported by
distributors but provided by third party device vendors, we can break
this spell and can lower the barrier for using TOMOYO.

This patch is intended for demonstrating that there is nothing difficult
for supporting TOMOYO-like loadable LSM modules. For now we need to live
with a mixture of built-in part and loadable part because fully loadable
LSM modules are not supported since Linux 2.6.24 [2] and number of LSMs
which can reserve static call slots is determined at compile time in
Linux 6.12.

Major changes in this patch are described below.
There are no behavior changes as long as TOMOYO is built into vmlinux.

Add CONFIG_SECURITY_TOMOYO_LKM as "bool" instead of changing
CONFIG_SECURITY_TOMOYO from "bool" to "tristate", for something went
wrong with how Makefile is evaluated if I choose "tristate".

Add proxy.c for serving as a bridge between vmlinux and tomoyo.ko .
Move callback functions from init.c to proxy.c when building as a loadable
LSM module. init.c is built-in part and remains for reserving static call
slots. proxy.c contains module's init function and tells init.c location of
callback functions, making it possible to use static call for tomoyo.ko .

By deferring initialization of "struct tomoyo_task" until tomoyo.ko is
loaded, threads created between init.c reserved LSM hooks and proxy.c
updates LSM hooks will have NULL "struct tomoyo_task" instances. Assuming
that tomoyo.ko is loaded by the moment when the global init process starts,
initialize "struct tomoyo_task" instance for current thread as a kernel
thread when tomoyo_task(current) is called for the first time.

There is a hack for exporting currently not-exported functions.
This hack will be removed after all relevant functions are exported.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=542986
Link: https://lkml.kernel.org/r/caafb609-8bef-4840-a080-81537356fc60@I-love.SAKURA.ne.jp
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
security/tomoyo/Kconfig
security/tomoyo/Makefile
security/tomoyo/common.c
security/tomoyo/common.h
security/tomoyo/init.c
security/tomoyo/load_policy.c
security/tomoyo/proxy.c [new file with mode: 0644]
security/tomoyo/securityfs_if.c