[PATCH v3 01/13] LSM: Add the lsm_prop data structure.

[Tetsuo Handa]

On 2024/09/14 19:30, Konstantin Andreev wrote:
> Casey Schaufler, 14 Sep 2024:
>> On 9/13/2024 1:49 PM, Konstantin Andreev wrote:
>>> Casey Schaufler, 10 Sep 2024:
>>>> ...
>>>> The lsm_prop structure definition is intended to keep the LSM
>>>> specific information private to the individual security modules.
>>>> ...
>>>> index 1390f1efb4f0..1027c802cc8c 100644
>>>> --- a/include/linux/security.h
>>>> +++ b/include/linux/security.h
>>>> @@ -140,6 +144,22 @@ enum lockdown_reason {
>>>> +
>>>> +/*
>>>> + * Data exported by the security modules
>>>> + */
>>>> +struct lsm_prop {
>>>> +    struct lsm_prop_selinux selinux;
>>>> +    struct lsm_prop_smack smack;
>>>> +    struct lsm_prop_apparmor apparmor;
>>>> +    struct lsm_prop_bpf bpf;
>>>> +    struct lsm_prop_scaffold scaffold;
>>>> +};
>>>
>>> This design prevents compiling and loading out-of-tree 3rd party LSM,
>>> am I right?
>>
>> No more so than the existing implementation. An upstream acceptable
>> scheme for loading out-of-tree LSMs has much bigger issues to address
>> than adding an element to struct lsm_prop.

What I imagine with "loadable LSMs" is "trivial LSMs which do not depend
on blobs managed by infrastructure but do depend on hooks being called
by infrastructure". Some of such LSMs could be implemented using BPF, but
BPF is too limited to re-implement TOMOYO (or TOMOYO-like LSMs).

TOMOYO is one of trivial LSMs which can easily opt out from "infrastructure
managed blobs". Also, I don't have a plan to allow "loadable LSMs" to use
"infrastructure managed blobs" including "struct lsm_prop".

>>
>>> Out-of-tree LSM's were discussed recently at
>>>
>>> https://lore.kernel.org/linux-security-module/efb8f264-f80e-43b2-8ea3-fcc9789520ec@I-love.SAKURA.ne.jp/T/
>>> https://lore.kernel.org/linux-security-module/960e740f-e5d9-409b-bb2a-8bdceffaae95@I-love.SAKURA.ne.jp/T/
>>>
>>> but it looks like a final decision to ban them is not taken yet.
>>
>> There has never been (to my knowledge) an effort to "ban" out-of-tree
>> LSMs. There has also not been interest in actively supporting them since
>> the "L" in LSM changed from "Loadable" to "Linux", with the exception of
>> Tetsuo Handa, who has been invited to suggest a viable mechanism. There
>> is currently support for BPF based security implementations, which can
>> be maintained out-of-tree. We are currently battling with the notion that
>> the LSM infrastructure is an attack surface. We really don't want to do
>> anything to increase that exposure.
> 
> Thank you for explaining this. Although the “ban” is a side effect of the
> other activity, I think the “ban” should be explicitly recognized as ban,
> rather than evasive “we don’t care”.

The "we don't care" response is really irritating. But if loadable LSMs were
banned, LSM will be dead and an alternative to LSM will be crazily pushed.
No one can enforce "military level security" to averaged Linux users.
That attempt is a reoccurrence of "Only my version is correct" crap.

Only those who needs "military level security" in LSM will use LSM.
Those who don't need "military level security" will use a different framework.

> 
> The reason I think so is that this decision significantly (at times)
> increases the cost of user (here: system owner) <-> 3rd party LSM developer
> interaction, and decreases openness of Linux in this particular aspect.

If loadable LSMs were banned, the value of distribution kernel will be
significantly lost. The point of loadable kernel module is to share the
workload.