LSM stacking in next for 6.1?

[Tetsuo Handa]

On 2022/09/15 16:45, John Johansen wrote:
> On 9/14/22 06:57, Tetsuo Handa wrote:
> for some users, but having a very well defined support surface also has its
> place. From a distro POV support is expensive and its amazing what users
> will do and try to hide while trying to get support.
> 

I know support is expensive. But distributors are not the only organizations
who provide support. Non-distributors can provide efforts for fixing bugs.
(In fact, I'm debugging problems where distributors would not care/support.)

> Personally I prefer splitting enable and support but there are situations
> where that isn't even allowed (some certifications). So I can understand
> where they are coming from.

What certifications require that an LSM must not be loaded as a loadable kernel
module?

I can imagine that certification becomes void if uncertified/extra kernel modules
are loaded. But I can't imagine that ability to load some kernel module (either
LSM or not) is relevant to certification.

>> I don't like closed-source kernel modules that rewrite syscall tables (e.g.
>> used by AntiVirus), for I can't analyze problems when something went wrong.
> 
> Does anyone?

Yes. It took me whole 2 years to prove that a timeout problem happening in a RHEL
system using TrendMicro's DeepSecurity is caused by a loadable kernel module used
by DeepSecurity. It is really difficult to analyze problems with closed-source
kernel modules, for I can't guess what is happening from source code.

You can browse how a loadable kernel module (for TrendMicro's ServerProtect) would look like
at https://files.trendmicro.com/products/splx/splx_kernel_module-3.0.1.0024-src.tar.gz .
I'm expecting that such loadable kernel module becomes cleaner by legally allowing
loadable LSM modules.

> 
>> If LSMs were available to open-source out-of-tree kernel modules, this situation
>> could be improved.
>>
> you are more optimistic than I am. What makes you think a distro like RH will
> enable loading out-of-tree kernel modules if they aren't enabling TOMOYO
> that is already in the kernel.
> 
> If loadable LSM modules are allowed, there will likely be a kernel config
> to disable them and there will definitely be an interface that allows
> blocking them. So whether via config option or run time control I don't
> see RH allowing them.

An interface that allows blocking unwanted loadable kernel module (either LSM or not)
will be e.g. module signature verification. No special switch for LSM is needed.

The "Vendor-A enables module-A" == "Vendor-A provides support for module-A" and
"Vendor-B enables module-B" == "Vendor-B provides support for module-B" rule can
apply to non-SELinux LSMs.