linux-kernel - Re: [PATCH v3 01/13] LSM: Add the lsm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8515a57b-4369-4bd9-a43f-b5543295a472@swemel.ru>
Date: Sat, 14 Sep 2024 13:30:11 +0300
From: Konstantin Andreev <andreev@...mel.ru>
To: Casey Schaufler <casey@...aufler-ca.com>, paul@...l-moore.com
Cc: linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org,
 Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Subject: Re: [PATCH v3 01/13] LSM: Add the lsm_prop data structure.

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