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

[Tetsuo Handa]

On 2022/11/08 3:59, Casey Schaufler wrote:
> 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.
> 

You are proving yourself that you are completely trapped into
"only in-tree and supported by distributors is correct" crap.

I am an individual who don't belong to specific distribution. Most of Linux users
in companies I relate with are using RHEL. Company's financial support for TOMOYO
terminated in March 2012 because I was not able to establish support/consult business
because I was not able to get TOMOYO enabled in RHEL (even in Fedora).

My support for TOMOYO is still continued, but unless loadable LSMs becomes legally
possible, I can't introduce TOMOYO/CaitSith to Linux users in companies I relate with.

Even if your LSM stacking work completes some day, I can imagine that there will be
no LSMs I can stack (unless loadable LSMs becomes legally possible).
Finding a distribution who want loadable LSMs does not help.
Only that loadable LSMs becomes legally possible without kernel config option helps.

What I'm asking you are that:

  Please don't lock out out-of-tree LSM modules (by requiring an LSM id integer value
  which are assigned to only in-tree LSM modules) because we can't accept whatever LSM
  modules as in-tree.

  Please don't lock out loadable LSM modules (by using fixed sized array) because
  locking out loadable LSM modules reduces the value of your LSM stacking work.

Quite simple.