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: <d6de966e-ff67-41a4-8a37-1709119be9fd@schaufler-ca.com>
Date: Fri, 13 Sep 2024 16:05:35 -0700
From: Casey Schaufler <casey@...aufler-ca.com>
To: Konstantin Andreev <andreev@...mel.ru>, paul@...l-moore.com
Cc: linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org,
 Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH v3 01/13] LSM: Add the lsm_prop data structure.

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
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ