mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2025-01-17 10:46:33 +00:00
8b985bbfab
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 [1] Link: https://lkml.kernel.org/r/caafb609-8bef-4840-a080-81537356fc60@I-love.SAKURA.ne.jp [2] Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
101 lines
3.9 KiB
Plaintext
101 lines
3.9 KiB
Plaintext
# SPDX-License-Identifier: GPL-2.0-only
|
|
config SECURITY_TOMOYO
|
|
bool "TOMOYO Linux Support"
|
|
depends on SECURITY
|
|
depends on NET
|
|
select SECURITYFS
|
|
select SECURITY_PATH
|
|
select SECURITY_NETWORK
|
|
default n
|
|
help
|
|
This selects TOMOYO Linux, pathname-based access control.
|
|
Required userspace tools and further information may be
|
|
found at <https://tomoyo.sourceforge.net/>.
|
|
If you are unsure how to answer this question, answer N.
|
|
|
|
config SECURITY_TOMOYO_LKM
|
|
bool "Cut out most of TOMOYO's code to a loadable kernel module"
|
|
default n
|
|
depends on SECURITY_TOMOYO
|
|
depends on MODULES
|
|
help
|
|
Say Y here if you want to include TOMOYO without bloating
|
|
vmlinux file. If you say Y, most of TOMOYO code is cut out to
|
|
a loadable kernel module named tomoyo.ko . This option will be
|
|
useful for kernels built by Linux distributors where TOMOYO is
|
|
included but TOMOYO is not enabled by default. Please be sure
|
|
to explicitly load tomoyo.ko if you want to activate TOMOYO
|
|
without calling userspace policy loader, for tomoyo.ko is
|
|
loaded immediately before calling userspace policy loader.
|
|
|
|
config SECURITY_TOMOYO_MAX_ACCEPT_ENTRY
|
|
int "Default maximal count for learning mode"
|
|
default 2048
|
|
range 0 2147483647
|
|
depends on SECURITY_TOMOYO
|
|
help
|
|
This is the default value for maximal ACL entries
|
|
that are automatically appended into policy at "learning mode".
|
|
Some programs access thousands of objects, so running
|
|
such programs in "learning mode" dulls the system response
|
|
and consumes much memory.
|
|
This is the safeguard for such programs.
|
|
|
|
config SECURITY_TOMOYO_MAX_AUDIT_LOG
|
|
int "Default maximal count for audit log"
|
|
default 1024
|
|
range 0 2147483647
|
|
depends on SECURITY_TOMOYO
|
|
help
|
|
This is the default value for maximal entries for
|
|
audit logs that the kernel can hold on memory.
|
|
You can read the log via /sys/kernel/security/tomoyo/audit.
|
|
If you don't need audit logs, you may set this value to 0.
|
|
|
|
config SECURITY_TOMOYO_OMIT_USERSPACE_LOADER
|
|
bool "Activate without calling userspace policy loader."
|
|
default n
|
|
depends on SECURITY_TOMOYO
|
|
help
|
|
Say Y here if you want to activate access control as soon as built-in
|
|
policy was loaded. This option will be useful for systems where
|
|
operations which can lead to the hijacking of the boot sequence are
|
|
needed before loading the policy. For example, you can activate
|
|
immediately after loading the fixed part of policy which will allow
|
|
only operations needed for mounting a partition which contains the
|
|
variant part of policy and verifying (e.g. running GPG check) and
|
|
loading the variant part of policy. Since you can start using
|
|
enforcing mode from the beginning, you can reduce the possibility of
|
|
hijacking the boot sequence.
|
|
|
|
config SECURITY_TOMOYO_POLICY_LOADER
|
|
string "Location of userspace policy loader"
|
|
default "/sbin/tomoyo-init"
|
|
depends on SECURITY_TOMOYO
|
|
depends on !SECURITY_TOMOYO_OMIT_USERSPACE_LOADER
|
|
help
|
|
This is the default pathname of policy loader which is called before
|
|
activation. You can override this setting via TOMOYO_loader= kernel
|
|
command line option.
|
|
|
|
config SECURITY_TOMOYO_ACTIVATION_TRIGGER
|
|
string "Trigger for calling userspace policy loader"
|
|
default "/sbin/init"
|
|
depends on SECURITY_TOMOYO
|
|
depends on !SECURITY_TOMOYO_OMIT_USERSPACE_LOADER
|
|
help
|
|
This is the default pathname of activation trigger.
|
|
You can override this setting via TOMOYO_trigger= kernel command line
|
|
option. For example, if you pass init=/bin/systemd option, you may
|
|
want to also pass TOMOYO_trigger=/bin/systemd option.
|
|
|
|
config SECURITY_TOMOYO_INSECURE_BUILTIN_SETTING
|
|
bool "Use insecure built-in settings for fuzzing tests."
|
|
default n
|
|
depends on SECURITY_TOMOYO
|
|
select SECURITY_TOMOYO_OMIT_USERSPACE_LOADER
|
|
help
|
|
Enabling this option forces minimal built-in policy and disables
|
|
domain/program checks for run-time policy modifications. Please enable
|
|
this option only if this kernel is built for doing fuzzing tests.
|