TOMOYO's pull request for v6.12

[Tetsuo Handa]

On 2024/10/04 22:11, Mickaël Salaün wrote:
> On Fri, Oct 04, 2024 at 07:50:05PM +0900, Tetsuo Handa wrote:
>> On 2024/10/04 1:29, Serge E. Hallyn wrote:
>>> Well, this didn't occur to me last night, but what I'd be curious to
>>> hear is whether Tetsuo has discussed this with RedHat.  Because unless
>>> this makes them say "ok we'll enable that", it still doesn't help him.
>>> And I don't imagine them agreeing to enable the CONFIG_TOMOYO_LKM.
>>
>> Majority of Linux users I work for are using Red Hat. But I have absolutely
> 
> My understanding is that Red Hat's customers must ask for a feature for
> it to be available (in a future version), so you should ask your users
> to support the request.

I myself is not a RHEL user. I use RockyLinux and Ubuntu for improving quality
of the upstream kernels via fixing bugs syzbot finds. (Unfortunately, currently
the "static call" change is preventing me from spending my resource for this
activity, for "static call" broke AKARI.)

My customers are RHEL users, and I'm working for their RHEL systems, with my
feeling that how their projects becomes easy if I can profile their systems
using TOMOYO. But my customers do not know about TOMOYO. I have no channel to
introduce TOMOYO to relevant persons who are in a position of giving
permissions for contacting Red Hat support using their RHEL subscriptions.

>> You might think that such LSM module is not a security. But TOMOYO is
>> also used as a sort of system-wide strace-like profiler. Understanding
>> what the users' systems are doing is useful/helpful for users.
> 
> I think an LSM is not the right tool for tracing because it only sees a
> subset of the access requests: other security mechanisms may deny
> requests before they reach an LSM.  Linux provides great tracing
> mechanisms though.

LSM is the best-fitting tool for my purpose.
You can see an example at https://youtu.be/5cgqbQI9bEM .



>> If one of Red Hat's worries that refusing requests due to broken policy is
>> gone, the barrier for enabling such LSM module in Red Hat's kernels will be
>> lowered. If such LSM module becomes available in Red Hat kernels, I might be
>> able to find room/chance to help/involve with Red Hat community.
> 
> The question is about potential maintenance cost vs. ROI, not only
> security policy issues.  I guess Red Hat would not care about bugs in
> non-default service configurations, eBPF programs, nor LSM policies, but
> they will if additional code potentially impacts other parts of the
> system and may increase the number of potential bugs, and then the
> maintenance cost.  Open source is not free for everyone.

Without ability to do conversations, potential maintenance cost vs. ROI
cannot be evaluated. And I can't gain chances/ability to do conversations
with relevant people...