When more than one security module is exporting data to audit and
networking sub-systems a single 32 bit integer is no longer
sufficient to represent the data. Add a structure to be used instead.
The lsm_prop structure definition is intended to keep the LSM
specific information private to the individual security modules.
The module specific information is included in a new set of
header files under include/lsm. Each security module is allowed
to define the information included for its use in the lsm_prop.
SELinux includes a u32 secid. Smack includes a pointer into its
global label list. The conditional compilation based on feature
inclusion is contained in the include/lsm files.
Suggested-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Cc: apparmor@lists.ubuntu.com
Cc: bpf@vger.kernel.org
Cc: selinux@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
---
include/linux/lsm/apparmor.h | 17 +++++++++++++++++
include/linux/lsm/bpf.h | 16 ++++++++++++++++
include/linux/lsm/selinux.h | 16 ++++++++++++++++
include/linux/lsm/smack.h | 17 +++++++++++++++++
include/linux/security.h | 20 ++++++++++++++++++++
5 files changed, 86 insertions(+)
create mode 100644 include/linux/lsm/apparmor.h
create mode 100644 include/linux/lsm/bpf.h
create mode 100644 include/linux/lsm/selinux.h
create mode 100644 include/linux/lsm/smack.h
diff --git a/include/linux/lsm/apparmor.h b/include/linux/lsm/apparmor.h
new file mode 100644
index 000000000000..612cbfacb072
--- /dev/null
+++ b/include/linux/lsm/apparmor.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Linux Security Module interface to other subsystems.
+ * AppArmor presents single pointer to an aa_label structure.
+ */
+#ifndef __LINUX_LSM_APPARMOR_H
+#define __LINUX_LSM_APPARMOR_H
+
+struct aa_label;
+
+struct lsm_prop_apparmor {
+#ifdef CONFIG_SECURITY_APPARMOR
+ struct aa_label *label;
+#endif
+};
+
+#endif /* ! __LINUX_LSM_APPARMOR_H */
diff --git a/include/linux/lsm/bpf.h b/include/linux/lsm/bpf.h
new file mode 100644
index 000000000000..8106e206fcef
--- /dev/null
+++ b/include/linux/lsm/bpf.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Linux Security Module interface to other subsystems.
+ * BPF may present a single u32 value.
+ */
+#ifndef __LINUX_LSM_BPF_H
+#define __LINUX_LSM_BPF_H
+#include <linux/types.h>
+
+struct lsm_prop_bpf {
+#ifdef CONFIG_BPF_LSM
+ u32 secid;
+#endif
+};
+
+#endif /* ! __LINUX_LSM_BPF_H */
diff --git a/include/linux/lsm/selinux.h b/include/linux/lsm/selinux.h
new file mode 100644
index 000000000000..9455a6b5b910
--- /dev/null
+++ b/include/linux/lsm/selinux.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Linux Security Module interface to other subsystems.
+ * SELinux presents a single u32 value which is known as a secid.
+ */
+#ifndef __LINUX_LSM_SELINUX_H
+#define __LINUX_LSM_SELINUX_H
+#include <linux/types.h>
+
+struct lsm_prop_selinux {
+#ifdef CONFIG_SECURITY_SELINUX
+ u32 secid;
+#endif
+};
+
+#endif /* ! __LINUX_LSM_SELINUX_H */
diff --git a/include/linux/lsm/smack.h b/include/linux/lsm/smack.h
new file mode 100644
index 000000000000..ff730dd7a734
--- /dev/null
+++ b/include/linux/lsm/smack.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Linux Security Module interface to other subsystems.
+ * Smack presents a pointer into the global Smack label list.
+ */
+#ifndef __LINUX_LSM_SMACK_H
+#define __LINUX_LSM_SMACK_H
+
+struct smack_known;
+
+struct lsm_prop_smack {
+#ifdef CONFIG_SECURITY_SMACK
+ struct smack_known *skp;
+#endif
+};
+
+#endif /* ! __LINUX_LSM_SMACK_H */
diff --git a/include/linux/security.h b/include/linux/security.h
index 1390f1efb4f0..1027c802cc8c 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -34,6 +34,10 @@
#include <linux/sockptr.h>
#include <linux/bpf.h>
#include <uapi/linux/lsm.h>
+#include <linux/lsm/selinux.h>
+#include <linux/lsm/smack.h>
+#include <linux/lsm/apparmor.h>
+#include <linux/lsm/bpf.h>
struct linux_binprm;
struct cred;
@@ -140,6 +144,22 @@ enum lockdown_reason {
LOCKDOWN_CONFIDENTIALITY_MAX,
};
+/* scaffolding */
+struct lsm_prop_scaffold {
+ u32 secid;
+};
+
+/*
+ * 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;
+};
+
extern const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1];
extern u32 lsm_active_cnt;
extern const struct lsm_id *lsm_idlist[];
--
2.46.0Casey 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.
--
Konstantin Andreev
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
>
On 2024/09/14 8:05, Casey Schaufler wrote:
> There has never been (to my knowledge) an effort to "ban" out-of-tree
> LSMs.
No, commit f3b8788cde61 ("LSM: Identify modules by more than name") is
an effort to "ban" out-of-tree LSMs.
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
On 2024/09/14 19:30, Konstantin Andreev wrote:
> 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.
What I imagine with "loadable LSMs" is "trivial LSMs which do not depend
on blobs managed by infrastructure but do depend on hooks being called
by infrastructure". Some of such LSMs could be implemented using BPF, but
BPF is too limited to re-implement TOMOYO (or TOMOYO-like LSMs).
TOMOYO is one of trivial LSMs which can easily opt out from "infrastructure
managed blobs". Also, I don't have a plan to allow "loadable LSMs" to use
"infrastructure managed blobs" including "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 "we don't care" response is really irritating. But if loadable LSMs were
banned, LSM will be dead and an alternative to LSM will be crazily pushed.
No one can enforce "military level security" to averaged Linux users.
That attempt is a reoccurrence of "Only my version is correct" crap.
Only those who needs "military level security" in LSM will use LSM.
Those who don't need "military level security" will use a different framework.
>
> 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.
If loadable LSMs were banned, the value of distribution kernel will be
significantly lost. The point of loadable kernel module is to share the
workload.
On Fri, Sep 13, 2024 at 4:49 PM Konstantin Andreev <andreev@swemel.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
Paul Moore, 14 Sep 2024:
> On Fri, Sep 13, 2024 at 4:49 PM Konstantin Andreev <andreev@swemel.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:
I have certainly seen your comment,
> "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."
but the matter of fact is … your dispute with Tetsuo Handa still continues.
You are sending controversal signals to the public.
--
Konstantin Andreev
© 2016 - 2024 Red Hat, Inc.