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: <CAHC9VhQfLRfKTjksZ=KxuNPHXXUAV_0Q0ejKEDmFXc82wOZu2g@mail.gmail.com>
Date: Fri, 13 Sep 2024 17:45:02 -0400
From: Paul Moore <paul@...l-moore.com>
To: Konstantin Andreev <andreev@...mel.ru>
Cc: Casey Schaufler <casey@...aufler-ca.com>, linux-kernel@...r.kernel.org, 
	linux-security-module@...r.kernel.org
Subject: Re: [PATCH v3 01/13] LSM: Add the lsm_prop data structure.

On Fri, Sep 13, 2024 at 4:49 PM Konstantin Andreev <andreev@...mel.ru> 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?
>
> 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.

For those who haven't read my latest comment in the v6.12 merge window
pull request, I'll copy-n-paste it here:

"My focus is on the upstream Linux kernel and ensuring that the
upstream, in-tree LSMs have the best framework possible to ensure
their proper operation and ease of development/maintenance.  While I
have no intention to negatively impact out-of-tree LSMs, I will not
harm the upstream code base solely to support out-of-tree LSMs.
Further, if improvements to the upstream LSM framework are determined
to harm out-of-tree LSMs, that shall be no reason to reject the
upstream improvements.  I believe this policy is not only consistent
with that of previous LSM maintainers, but of the general Linux kernel
as well."

-- 
paul-moore.com