TOMOYO's pull request for v6.12

[Tetsuo Handa]

On 2024/10/05 5:54, Kees Cook wrote:
> - tomoyo_register_hooks() becomes an exploitation gadget that could be
>   used to bypass the LSM as a whole.

tomoyo_register_hooks() is enabled only if "CONFIG_SECURITY_TOMOYO_LKM is
included while building the kernel" && "security=tomoyo is specified or
tomoyo is included in the lsm= kernel command line options".

Therefore, those who are building kernels with CONFIG_SECURITY_TOMOYO_LKM=n are
not affected.

Even if kernels are built with CONFIG_SECURITY_TOMOYO_LKM=y, callbacks
registered by tomoyo_register_hooks() won't be called unless "security=tomoyo
is specified or tomoyo is included in the lsm= kernel command line options", for
the proxy callbacks that use static call tables are not registered.

Even if kernels are built with CONFIG_SECURITY_TOMOYO_LKM=y, and "security=tomoyo
is specified or tomoyo is included in the lsm= kernel command line options",
tomoyo_register_hooks() can be called only once. And tomoyo.ko is loaded by the
time /sbin/init (nowadays /usr/lib/systemd/systemd) starts. That is, by the time
an attacker can login from console or can start attacking via network,
tomoyo_register_hooks() is no longer callable.

If an attacker can control boot behavior before /sbin/init (nowadays
/usr/lib/systemd/systemd) starts (e.g. by editing kernel boot command line, or
loading malicious kernel module from initramfs before tomoyo.ko is loaded), that
system was already compromised and is a different problem. (If kernel command line
options were modified to enable only capability (i.e. "lsm=capability"), how can
selinux/apparmor etc. can protect that system?)

Therefore, the only problem with tomoyo.ko approach is that the static call tables
for tomoyo_register_hooks() are currently not marked as __ro_after_init. But it will
be possible to make the static call tables read-only if the static call tables
are aligned in a page boundary and an architecture-dependent kernel API that changes
given page's attribute to read-only is called. (This is why __ro_after_init can work,
isn't it?)

As a whole, I don't think tomoyo.ko approach is unacceptably dangerous.