On 2022/10/28 18:50, Paul Moore wrote:
>> This problem is not limited to out-of-tree and/or
>> loadable LSM modules. This change prevents new LSM modules from getting upstream
>> due to a chicken-and-egg problem.
>
> It does *not* prevent new LSM modules from being merged upstream.
>
> It may make it more difficult for out-of-tree modules to remain
> out-of-tree, but that is both not a concern of the upstream community
> nor is it the concern you are currently describing.
New LSM modules are out-of-tree modules until being merged upstream.
LSM modules is an area which is difficult to get merged upstream for
unknown reasons. You remember the label versus pathname war, don't you?
Do you remember that 10 modules were proposed
SimpleFlow ( 2016/04/21 https://lwn.net/Articles/684825/ )
HardChroot ( 2016/07/29 https://lwn.net/Articles/695984/ )
Checmate ( 2016/08/04 https://lwn.net/Articles/696344/ )
LandLock ( 2016/08/25 https://lwn.net/Articles/698226/ )
PTAGS ( 2016/09/29 https://lwn.net/Articles/702639/ )
CaitSith ( 2016/10/21 https://lwn.net/Articles/704262/ )
SafeName ( 2016/05/03 https://lwn.net/Articles/686021/ )
WhiteEgret ( 2017/05/30 https://lwn.net/Articles/724192/ )
shebang ( 2017/06/09 https://lwn.net/Articles/725285/ )
S.A.R.A. ( 2017/06/13 https://lwn.net/Articles/725230/ )
and how many of them got merged upstream? It is inevitable that some
(or rather, many or most) of LSM modules cannot be merged upstream or
be enabled by distributors.
Even if perfect LSM stacking is implemented, I can imagine a future that
none of LSM modules available in upstream kernel can satisfy user's needs.
LSM stacking makes sense only if LSM modules which can satisfy user's needs
are available. And we know that upstream kernel won't accept whatever LSMs.
I consider /sbin/insmod-able LSM modules as a compromise/remedy for LSM modules
which could not get merged upstream or supported by distributors, for patching and
rebuilding the whole kernel in order to use not-yet-upstreamed and/or not-builtin
LSMs is already a lot of barrier for users. But requiring a permanent integer in
order to use a LSM module is a denial of even patching and rebuilding the whole
kernel. That's why I hate this change.
>
>> Currently anyone can start writing new LSM modules using name as identifier. But
>> you are trying to forbid using name as identifier, and trying to force using integer
>> as identifier, but that integer will not be provided unless new LSM modules get
>> upstream.
>
> That is correct. In order to have a LSM identifier token the LSM must
> be upstream.
Then, new LSM modules which are intended to be merged upstream can't write
userspace interface.
>
>> Then, how those who want to write new LSM modules can start writing LSM modules and
>> propose userspace changes for new LSM modules? They can't use the identifier unless
>> their LSM module get upstream, which in turn forces them not to propose interface for
>> userspace programs, which in turn makes it difficult to get new LSM modules tested
>> by users, which in turn makes it difficult to get upstream due to "who is using your
>> LSM module" question, which in turn makes it difficult to get the identifier...
>
> First, new LSMs generally do not need extensive userspace
> modifications; of course there may be some, but when one considers the
> entirety of a modern Linux distribution the actual percentage should
> be quite small.
I agree that new LSMs generally do not need extensive userspace modifications.
But
> In addition, it is not uncommon for in-development
> LSMs to have a set of privately, i.e. not upstreamed, patched
> userspace tools while the new LSM works to get upstream. These
> private userspace patches are generally merged after the LSM has been
> merged into the kernel.
I still think an identifier is needed when developing management programs for each
new LSM.
Do you mean that management programs which are specific to each LSM module are not
forced to use the identifier Casey is trying to introduce? If yes, why does "you are
trying to forbid using name as identifier, and trying to force using integer as
identifier" need to be correct? Only programs that do not belong to specific LSM
module but needs to be able to recognize various LSM modules' per task attributes
need to use the identifier Casey is trying to introduce.
I can't understand why assigning a permanent integer identifier is mandatory.
TOMOYO (and trivial LSMs) will not need such identifier. This change merely makes
it more difficult to stack minor/trivial LSMs implemented as /sbin/insmod-able LSMs,
by introducing fixed sized array.
>
>> You are trying to force CONFIG_MODULES=n by just "we don't care about out-of-tree code".
>
> That is not the goal at all and I would appreciate it if you could
> stop slandering the motivations of the LSM syscall effort.
>
>> Trying to change identifier from name to integer is a serious bug.
>
> I disagree. One would have a similar problem - userspace
> awareness/enablement - regardless of if a name or a token is used.
TOMOYO (and trivial LSMs) will not need userspace awareness/enablement.
> Ultimately the challenge is getting userspace developers to accept a
> change that is not part of the upstream Linux Kernel and thus not
> guaranteed under the usual "don't break userspace" kernel API promise.
I'm not against the challenge. But none of "introducing fixed sized array",
"assigning permanent integer for the fixed sized array", "not assigning permanent
integer unless merged upstream" is required for achieving the challenge. We can
achieve the challenge via "using linked list" and "using name or assigning dynamic
integer upon loading of a LSM module". (Of course, if upstream kernel allows assigning
permanent integer before getting merged, we can use integer for the userspace...)
