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

[Konstantin Andreev]

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.
> 
>> 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 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.
--
Konstantin Andreev