TOMOYO's pull request for v6.12

Mickaël Salaün mic at digikod.net
Fri Oct 4 13:11:01 UTC 2024


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 wish Landlock would be available everywhere too, but this requires
some effort.  Even when an LSM is built-in, it may not be enabled by
default and then not available to most users because of the "lsm="
cmdline or CONFIG_LSM...  To protect as much users as possible
(potentially without their knowledge), we have the burden of convincing
distros and other parts of the Linux ecosystems that a security feature
is worth it.

> too little relationship with Red Hat people to involve somebody else into
> this problem. Too little attention/interest to make progress.
> https://bugzilla.redhat.com/show_bug.cgi?id=2303689
> 
> Chicken-and-egg problem here; since TOMOYO is not available in Red Hat
> kernels, I have no room/chance to help/involve with Red Hat community.
> 
> If I implement a subset of TOMOYO that does not refuse requests (something
> like SELinux without the "enforcing mode"), can such LSM module be accepted
> by the upstream kernel? (The "patent examination" is a barrier for doing it.)
> 
> 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.

> 
> 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.



More information about the Linux-security-module-archive mailing list