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

[Casey Schaufler <casey@schaufler-ca.com>]

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.

> -- 
> Konstantin Andreev
>