[PATCH 04/10] CaitSith: Add header file.

Casey Schaufler casey at schaufler-ca.com
Mon Nov 7 18:59:44 UTC 2022


On 11/5/2022 5:56 PM, Tetsuo Handa wrote:
> On 2022/11/06 8:46, Serge E. Hallyn wrote:
>> On Sat, Nov 05, 2022 at 01:05:44PM +0900, Tetsuo Handa wrote:
>>> On 2022/11/05 11:43, Serge E. Hallyn wrote:
>>>> On Wed, Nov 02, 2022 at 10:57:48AM -0700, Casey Schaufler wrote:
>>>>> On 11/2/2022 10:10 AM, Tetsuo Handa wrote:
>>>>>> The main point of this submission is to demonstrate how an LSM module
>>>>>> which can be loaded using /sbin/insmod can work, and to provide
>>>>>> consideration points for making changes for LSM stacking in a way that
>>>>>> will not lock out LSM modules which can be loaded using /sbin/insmod .
>>>>> CaitSith could readily be done as an in-tree LSM. The implementation
>>>>> of loadable module infrastructure is unnecessary.
>>>> Sorry, I'm getting confused.  But in-tree and loadable are not related,
>>>> right?
>>> Very much related. My goal is to get CaitSith in-tree as a loadable LSM module
>>> which can be loaded using /sbin/insmod .
>> Great.  I support that.  But the sentence
> Thank you.
>
>>>>> CaitSith could readily be done as an in-tree LSM. The implementation
>>>>> of loadable module infrastructure is unnecessary.
>> suggests that because CaitSith could be done in-tree, it doesn't need
>> to be loadable.  I'm saying that is a non sequitur.  It sounded like
>> that setence was meant to say "Because CaitSith could be in-tree, it
>> doesn't need to be =m.  Only out of tree modules need to be loadable."
> Unfortunately, I don't think that my intended Linux distributor (namely, Red Hat)
> will support LSMs other than SELinux.

I also doubt that even if you came up with a 100% perfect implementation
of loadable module support it would be accepted upstream. If you somehow
got it upstream I really, really think it would be required to be optional.
There's no way Redhat would enable loadable module support if were available.
I am perfectly willing to be corrected if I've made a statement here that
isn't true, but I'll bet a refreshing beverage on it.

>
>   https://bugzilla.redhat.com/show_bug.cgi?id=542986
>
> Therefore, not only out of tree modules but also in-tree modules which cannot be
> enabled by Linux distributors need to be implemented as loadable kernel modules.

Today you cannot use SELinux and AppArmor together on Redhat. Someday
"soon ;)" you won't be allowed to run them together on Redhat. If there's
market demand (I'm not holding my breath) it could happen in the future.
But that's up to Redhat to decide. I don't see Redhat as the customer for
LSM improvements. They are happy with what they have.

You have to take a different approach. Find a distribution that does want
loadable modules. You'll need a viable implementation to convince them to
help with the effort. Even then, you'll have a tough row to hoe.




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