TOMOYO's pull request for v6.12

[Tetsuo Handa]

On 2024/10/06 9:02, Serge E. Hallyn wrote:
> On Sat, Oct 05, 2024 at 07:28:35PM +0200, Simon Thoby wrote:
> ...
>> Perhaps you would be better served by providing your users with a snippet of documentation
>> explaining how to configure MOK and to rebuild the RHEL kernel with TOMOYO enabled?
>> To be fair, I know that your customers may find this a time-consuming ordeal compared to using
>> the official kernel - especially as you want to keep up with the frequent updates.
> 
> Tetsuo's problem, AIUI, is not that it's difficult to rebuild the kernel enabling
> tomoyo, it's that once his customers do so, RedHat will not support/debug in case
> of failures.

There are a lot of problems.

TOMOYO is a personal project (the company when I wrote TOMOYO is no longer
involved since 2012). Also, the company I currently belong to does not have
much involvement in OSS community. There are some Java programmers, but there
are little C programmers. Programmers who can understand the Linux kernel are
endangered species. And I'm working as a troubleshooting staff who can investigate
problems using C programmer's skill / Linux kernel developer's knowledge.

Because such a situation, talking with managers needs to be done at a level for
non-programmers, and communicating with developers/operators needs to be done
using almost copy-and-paste level procedure manual. In short, Linux systems are
black-box for them, and I want to use TOMOYO as one of tools for helping them to
escape from black-box.

Most of Linux systems are RHEL servers, but since TOMOYO is not included in RHEL
kernels, I can't use TOMOYO. I was using AKARI until now, but the "static calls"
change broke AKARI. Thus, I'm close to panic() condition.

As far as I'm involved in, all RHEL servers are running inside protected
environment (e.g. commercial WAF/IPS devices inspect traffics before forwarding,
commercial firewalls/LBs devices minimize possible networking communication
routes, SSO is enforced for users to login, AV/EDR are protecting individual
server). Because such a situation, there is little needs for updating packages
due to security bugs. It may not be a good practice, but even packages that
reached EOL might be used for years after EOL. For such environments, e.g.
TSC counter overflows after 208.5 days and freezes the system is more impacting
problem and is the reason to update kernel packages.

I could rebuild RHEL kernels with TOMOYO enabled. But I can't afford providing
infrastructure for distributing rebuilt kernels / packages relevant with the
rebuilt kernels (e.g. debuginfo packages) nor resource for acting as front-end
for receiving any problems that happens with the rebuilt kernels. How difficult
will it be to let my customers rebuild RHEL kernels with TOMOYO enabled and
let my customers prove Red Hat that the cause of their problem (bugs) is in
stock RHEL kernels? (Not limited to runtime bugs, but also questions etc. for
configuring kernel part that is not related to TOMOYO.) As with problems that
happen when using e.g. out-of-tree products, I need to rely on Linux distributor
as front-end. As a back-end, I will handle problems (bugs) in TOMOYO part.

It is AV / EDR companies who are most thinking empathetically and contributing
to security for my customer's individual RHEL servers. What the LSM community
considers as threats and what my customers consider as threats are different.
It is sad that the LSM community does not like e.g. loadable LSM modules despite
writable variables are not a practical attack vector for my customers...



Going back to tomoyo.ko seen from my customers point of view.

Advantage of building TOMOYO into vmlinux is that the procedure for
communicating with managers/developers/operators becomes simple.

Advantage of building TOMOYO as tomoyo.ko is that users can update only
tomoyo.ko (thanks to KABI in RHEL kernels) when a bug is found in TOMOYO.
Minimizing possible code changes helps minimizing cost for updating packages.
But secure boot / module signing (not a topic to consider for current
environment, but possibly becomes a topic to consider for future environment)
needs to be taken into account.

I'm not familiar with secure boot / module signing. I had a feeling that effectively
only distributors can sign tomoyo.ko . But it seems that I can also sign tomoyo.ko
if conditions are met. But I won't be able to provide infrastructure / support for
problems related to secure boot, for I need to prepare copy-and-paste level
procedure manual (not a snippet!) and support. tomoyo.ko being signed by
distributors is much appreciated.