From: Roberto Sassu <[email protected]>
Since the integrity (including IMA and EVM) functions are currently always
called by the LSM infrastructure, and always after all LSMs, formalize
these requirements by introducing a new LSM ordering called LSM_ORDER_LAST,
and set it for the 'integrity' LSM (patch 1).
Consequently, revert commit 92063f3ca73a ("integrity: double check
iint_cache was initialized"), as the double check becomes always verified
(patch 2), and remove 'integrity' from the list of LSMs in
security/Kconfig (patch 3).
Changelog:
v2:
- Fix commit message in patch 1 (suggested by Mimi)
- Bump version of patch 2 (v1 -> v3) to make one patch set
- Add patch 3 (suggested by Mimi)
v1:
- Add comment for LSM_ORDER_LAST definition (suggested by Mimi)
- Add Fixes tag (suggested by Mimi)
- Do minor corrections in the commit messages (suggested by Mimi and
Stefan)
Roberto Sassu (3):
security: Introduce LSM_ORDER_LAST and set it for the integrity LSM
Revert "integrity: double check iint_cache was initialized"
security: Remove integrity from the LSM list in Kconfig
include/linux/lsm_hooks.h | 1 +
security/Kconfig | 10 +++++-----
security/integrity/iint.c | 9 +--------
security/security.c | 12 +++++++++---
4 files changed, 16 insertions(+), 16 deletions(-)
--
2.25.1
From: Roberto Sassu <[email protected]>
With the recent introduction of LSM_ORDER_LAST, the 'integrity' LSM is
always initialized and the iint_cache is always created (the kernel panics
on error). Thus, the additional check of iint_cache in
integrity_inode_get() is no longer necessary.
This reverts commit 92063f3ca73aab794bd5408d3361fd5b5ea33079.
Signed-off-by: Roberto Sassu <[email protected]>
---
security/integrity/iint.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/security/integrity/iint.c b/security/integrity/iint.c
index b97eb59e0e3..c73858e8c6d 100644
--- a/security/integrity/iint.c
+++ b/security/integrity/iint.c
@@ -98,14 +98,6 @@ struct integrity_iint_cache *integrity_inode_get(struct inode *inode)
struct rb_node *node, *parent = NULL;
struct integrity_iint_cache *iint, *test_iint;
- /*
- * The integrity's "iint_cache" is initialized at security_init(),
- * unless it is not included in the ordered list of LSMs enabled
- * on the boot command line.
- */
- if (!iint_cache)
- panic("%s: lsm=integrity required.\n", __func__);
-
iint = integrity_iint_find(inode);
if (iint)
return iint;
--
2.25.1
From: Roberto Sassu <[email protected]>
Remove 'integrity' from the list of LSMs in Kconfig, as it is no longer
necessary. Since the recent change (set order to LSM_ORDER_LAST), the
'integrity' LSM is always enabled.
Signed-off-by: Roberto Sassu <[email protected]>
---
security/Kconfig | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/security/Kconfig b/security/Kconfig
index e6db09a779b..e109b4d5616 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -246,11 +246,11 @@ endchoice
config LSM
string "Ordered list of enabled LSMs"
- default "landlock,lockdown,yama,loadpin,safesetid,integrity,smack,selinux,tomoyo,apparmor,bpf" if DEFAULT_SECURITY_SMACK
- default "landlock,lockdown,yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo,bpf" if DEFAULT_SECURITY_APPARMOR
- default "landlock,lockdown,yama,loadpin,safesetid,integrity,tomoyo,bpf" if DEFAULT_SECURITY_TOMOYO
- default "landlock,lockdown,yama,loadpin,safesetid,integrity,bpf" if DEFAULT_SECURITY_DAC
- default "landlock,lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf"
+ default "landlock,lockdown,yama,loadpin,safesetid,smack,selinux,tomoyo,apparmor,bpf" if DEFAULT_SECURITY_SMACK
+ default "landlock,lockdown,yama,loadpin,safesetid,apparmor,selinux,smack,tomoyo,bpf" if DEFAULT_SECURITY_APPARMOR
+ default "landlock,lockdown,yama,loadpin,safesetid,tomoyo,bpf" if DEFAULT_SECURITY_TOMOYO
+ default "landlock,lockdown,yama,loadpin,safesetid,bpf" if DEFAULT_SECURITY_DAC
+ default "landlock,lockdown,yama,loadpin,safesetid,selinux,smack,tomoyo,apparmor,bpf"
help
A comma-separated list of LSMs, in initialization order.
Any LSMs left off this list will be ignored. This can be
--
2.25.1
From: Roberto Sassu <[email protected]>
Introduce LSM_ORDER_LAST, to satisfy the requirement of LSMs needing to be
last, e.g. the 'integrity' LSM, without changing the kernel command line or
configuration.
Also, set this order for the 'integrity' LSM. While not enforced, this is
the only LSM expected to use it.
Similarly to LSM_ORDER_FIRST, LSMs with LSM_ORDER_LAST are always enabled
and put at the end of the LSM list.
Finally, for LSM_ORDER_MUTABLE LSMs, set the found variable to true if an
LSM is found, regardless of its order. In this way, the kernel would not
wrongly report that the LSM is not built-in in the kernel if its order is
LSM_ORDER_LAST.
Fixes: 79f7865d844c ("LSM: Introduce "lsm=" for boottime LSM selection")
Signed-off-by: Roberto Sassu <[email protected]>
---
include/linux/lsm_hooks.h | 1 +
security/integrity/iint.c | 1 +
security/security.c | 12 +++++++++---
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 6e156d2acff..c55761d93a2 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -1716,6 +1716,7 @@ extern void security_add_hooks(struct security_hook_list *hooks, int count,
enum lsm_order {
LSM_ORDER_FIRST = -1, /* This is only for capabilities. */
LSM_ORDER_MUTABLE = 0,
+ LSM_ORDER_LAST = 1, /* This is only for integrity. */
};
struct lsm_info {
diff --git a/security/integrity/iint.c b/security/integrity/iint.c
index 8638976f799..b97eb59e0e3 100644
--- a/security/integrity/iint.c
+++ b/security/integrity/iint.c
@@ -182,6 +182,7 @@ static int __init integrity_iintcache_init(void)
DEFINE_LSM(integrity) = {
.name = "integrity",
.init = integrity_iintcache_init,
+ .order = LSM_ORDER_LAST,
};
diff --git a/security/security.c b/security/security.c
index cf6cc576736..2f36229d5b6 100644
--- a/security/security.c
+++ b/security/security.c
@@ -284,9 +284,9 @@ static void __init ordered_lsm_parse(const char *order, const char *origin)
bool found = false;
for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
- if (lsm->order == LSM_ORDER_MUTABLE &&
- strcmp(lsm->name, name) == 0) {
- append_ordered_lsm(lsm, origin);
+ if (strcmp(lsm->name, name) == 0) {
+ if (lsm->order == LSM_ORDER_MUTABLE)
+ append_ordered_lsm(lsm, origin);
found = true;
}
}
@@ -306,6 +306,12 @@ static void __init ordered_lsm_parse(const char *order, const char *origin)
}
}
+ /* LSM_ORDER_LAST is always last. */
+ for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
+ if (lsm->order == LSM_ORDER_LAST)
+ append_ordered_lsm(lsm, " last");
+ }
+
/* Disable all LSMs not in the ordered list. */
for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
if (exists_ordered_lsm(lsm))
--
2.25.1
On Thu, 2023-03-09 at 09:54 +0100, Roberto Sassu wrote:
> From: Roberto Sassu <[email protected]>
>
> Introduce LSM_ORDER_LAST, to satisfy the requirement of LSMs needing to be
> last, e.g. the 'integrity' LSM, without changing the kernel command line or
> configuration.
>
> Also, set this order for the 'integrity' LSM. While not enforced, this is
> the only LSM expected to use it.
>
> Similarly to LSM_ORDER_FIRST, LSMs with LSM_ORDER_LAST are always enabled
> and put at the end of the LSM list.
>
> Finally, for LSM_ORDER_MUTABLE LSMs, set the found variable to true if an
> LSM is found, regardless of its order. In this way, the kernel would not
> wrongly report that the LSM is not built-in in the kernel if its order is
> LSM_ORDER_LAST.
>
> Fixes: 79f7865d844c ("LSM: Introduce "lsm=" for boottime LSM selection")
> Signed-off-by: Roberto Sassu <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>
On Thu, 2023-03-09 at 09:54 +0100, Roberto Sassu wrote:
> From: Roberto Sassu <[email protected]>
>
> With the recent introduction of LSM_ORDER_LAST, the 'integrity' LSM is
> always initialized and the iint_cache is always created (the kernel panics
> on error). Thus, the additional check of iint_cache in
> integrity_inode_get() is no longer necessary.
>
> This reverts commit 92063f3ca73aab794bd5408d3361fd5b5ea33079.
>
> Signed-off-by: Roberto Sassu <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>
On Thu, 2023-03-09 at 09:54 +0100, Roberto Sassu wrote:
> From: Roberto Sassu <[email protected]>
>
> Remove 'integrity' from the list of LSMs in Kconfig, as it is no longer
> necessary. Since the recent change (set order to LSM_ORDER_LAST), the
> 'integrity' LSM is always enabled.
>
> Signed-off-by: Roberto Sassu <[email protected]>
> ---
> security/Kconfig | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/security/Kconfig b/security/Kconfig
> index e6db09a779b..e109b4d5616 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -246,11 +246,11 @@ endchoice
>
> config LSM
> string "Ordered list of enabled LSMs"
> - default "landlock,lockdown,yama,loadpin,safesetid,integrity,smack,selinux,tomoyo,apparmor,bpf" if DEFAULT_SECURITY_SMACK
> - default "landlock,lockdown,yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo,bpf" if DEFAULT_SECURITY_APPARMOR
> - default "landlock,lockdown,yama,loadpin,safesetid,integrity,tomoyo,bpf" if DEFAULT_SECURITY_TOMOYO
> - default "landlock,lockdown,yama,loadpin,safesetid,integrity,bpf" if DEFAULT_SECURITY_DAC
> - default "landlock,lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf"
> + default "landlock,lockdown,yama,loadpin,safesetid,smack,selinux,tomoyo,apparmor,bpf" if DEFAULT_SECURITY_SMACK
> + default "landlock,lockdown,yama,loadpin,safesetid,apparmor,selinux,smack,tomoyo,bpf" if DEFAULT_SECURITY_APPARMOR
> + default "landlock,lockdown,yama,loadpin,safesetid,tomoyo,bpf" if DEFAULT_SECURITY_TOMOYO
> + default "landlock,lockdown,yama,loadpin,safesetid,bpf" if DEFAULT_SECURITY_DAC
> + default "landlock,lockdown,yama,loadpin,safesetid,selinux,smack,tomoyo,apparmor,bpf"
> help
> A comma-separated list of LSMs, in initialization order.
> Any LSMs left off this list will be ignored. This can be
This comment should be updated to reflect the LSM_ORDER_FIRST and
LSM_ORDER_LAST LSMs are included as well.
Otherwise,
Signed-off-by: Mimi Zohar <[email protected]>
On Thu, 2023-03-09 at 08:20 -0500, Mimi Zohar wrote:
> On Thu, 2023-03-09 at 09:54 +0100, Roberto Sassu wrote:
> > From: Roberto Sassu <[email protected]>
> >
> > Remove 'integrity' from the list of LSMs in Kconfig, as it is no longer
> > necessary. Since the recent change (set order to LSM_ORDER_LAST), the
> > 'integrity' LSM is always enabled.
> >
> > Signed-off-by: Roberto Sassu <[email protected]>
> > ---
> > security/Kconfig | 10 +++++-----
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/security/Kconfig b/security/Kconfig
> > index e6db09a779b..e109b4d5616 100644
> > --- a/security/Kconfig
> > +++ b/security/Kconfig
> > @@ -246,11 +246,11 @@ endchoice
> >
> > config LSM
> > string "Ordered list of enabled LSMs"
> > - default "landlock,lockdown,yama,loadpin,safesetid,integrity,smack,selinux,tomoyo,apparmor,bpf" if DEFAULT_SECURITY_SMACK
> > - default "landlock,lockdown,yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo,bpf" if DEFAULT_SECURITY_APPARMOR
> > - default "landlock,lockdown,yama,loadpin,safesetid,integrity,tomoyo,bpf" if DEFAULT_SECURITY_TOMOYO
> > - default "landlock,lockdown,yama,loadpin,safesetid,integrity,bpf" if DEFAULT_SECURITY_DAC
> > - default "landlock,lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf"
> > + default "landlock,lockdown,yama,loadpin,safesetid,smack,selinux,tomoyo,apparmor,bpf" if DEFAULT_SECURITY_SMACK
> > + default "landlock,lockdown,yama,loadpin,safesetid,apparmor,selinux,smack,tomoyo,bpf" if DEFAULT_SECURITY_APPARMOR
> > + default "landlock,lockdown,yama,loadpin,safesetid,tomoyo,bpf" if DEFAULT_SECURITY_TOMOYO
> > + default "landlock,lockdown,yama,loadpin,safesetid,bpf" if DEFAULT_SECURITY_DAC
> > + default "landlock,lockdown,yama,loadpin,safesetid,selinux,smack,tomoyo,apparmor,bpf"
> > help
> > A comma-separated list of LSMs, in initialization order.
> > Any LSMs left off this list will be ignored. This can be
>
> This comment should be updated to reflect the LSM_ORDER_FIRST and
> LSM_ORDER_LAST LSMs are included as well.
Oh, ok. Will resend shortly.
Thanks
Roberto
> Otherwise,
> Signed-off-by: Mimi Zohar <[email protected]>
>
>
>
>
On Thu, Mar 9, 2023 at 8:21 AM Mimi Zohar <[email protected]> wrote:
> On Thu, 2023-03-09 at 09:54 +0100, Roberto Sassu wrote:
> > From: Roberto Sassu <[email protected]>
> >
> > Introduce LSM_ORDER_LAST, to satisfy the requirement of LSMs needing to be
> > last, e.g. the 'integrity' LSM, without changing the kernel command line or
> > configuration.
> >
> > Also, set this order for the 'integrity' LSM. While not enforced, this is
> > the only LSM expected to use it.
> >
> > Similarly to LSM_ORDER_FIRST, LSMs with LSM_ORDER_LAST are always enabled
> > and put at the end of the LSM list.
> >
> > Finally, for LSM_ORDER_MUTABLE LSMs, set the found variable to true if an
> > LSM is found, regardless of its order. In this way, the kernel would not
> > wrongly report that the LSM is not built-in in the kernel if its order is
> > LSM_ORDER_LAST.
> >
> > Fixes: 79f7865d844c ("LSM: Introduce "lsm=" for boottime LSM selection")
> > Signed-off-by: Roberto Sassu <[email protected]>
>
> Signed-off-by: Mimi Zohar <[email protected]>
Warning: procedural nitpicking ahead ...
The 'Signed-off-by' tag is in reference to the DCO, which makes sense
to add if you are a patch author or are merging a patch into a tree,
but it doesn't make much sense as a ACK/thumbs-up; this is why we have
the 'Acked-by' and 'Reviewed-by' tags. I generally read the
'Acked-by' tag as "I'm the one responsible for a chunk of code
affected by this patch and I'm okay with this change" and the
'Reviewed-by' tag as "I looked at this patch and it looks like a good
change to me". Perhaps surprisingly to some, while an 'Acked-by' is a
requirement for merging in a lot of cases, I appreciate 'Reviewed-by'
tags much more as it indicates the patch is getting some third-part
eyeballs on it ... so all you lurkers on this list, if you're
reviewing patches as they hit your inbox, don't be shy about posting
your 'Reviewed-by' tag if your comfortable doing so, we all welcome
the help :)
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
--
paul-moore.com
On Thu, Mar 9, 2023 at 3:55 AM Roberto Sassu
<[email protected]> wrote:
>
> From: Roberto Sassu <[email protected]>
>
> Introduce LSM_ORDER_LAST, to satisfy the requirement of LSMs needing to be
> last, e.g. the 'integrity' LSM, without changing the kernel command line or
> configuration.
>
> Also, set this order for the 'integrity' LSM. While not enforced, this is
> the only LSM expected to use it.
>
> Similarly to LSM_ORDER_FIRST, LSMs with LSM_ORDER_LAST are always enabled
> and put at the end of the LSM list.
Since you are respinning this patchset anyway, I might make it clear
that the LSM_ORDER_LAST LSMs are always enabled only when they are
enabled at kernel configure/build time. Simply marking a LSM as
LSM_ORDER_LAST does not mean you don't have to explicitly select the
LSM in the rest of the Kconfig.
> Finally, for LSM_ORDER_MUTABLE LSMs, set the found variable to true if an
> LSM is found, regardless of its order. In this way, the kernel would not
> wrongly report that the LSM is not built-in in the kernel if its order is
> LSM_ORDER_LAST.
>
> Fixes: 79f7865d844c ("LSM: Introduce "lsm=" for boottime LSM selection")
> Signed-off-by: Roberto Sassu <[email protected]>
> ---
> include/linux/lsm_hooks.h | 1 +
> security/integrity/iint.c | 1 +
> security/security.c | 12 +++++++++---
> 3 files changed, 11 insertions(+), 3 deletions(-)
--
paul-moore.com
On Thu, Mar 9, 2023 at 3:55 AM Roberto Sassu
<[email protected]> wrote:
>
> From: Roberto Sassu <[email protected]>
>
> Remove 'integrity' from the list of LSMs in Kconfig, as it is no longer
> necessary. Since the recent change (set order to LSM_ORDER_LAST), the
> 'integrity' LSM is always enabled.
See my comment in 1/3 about "always enabled".
> Signed-off-by: Roberto Sassu <[email protected]>
> ---
> security/Kconfig | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
--
paul-moore.com
On Thu, 2023-03-09 at 18:44 -0500, Paul Moore wrote:
> On Thu, Mar 9, 2023 at 3:55 AM Roberto Sassu
> <[email protected]> wrote:
> > From: Roberto Sassu <[email protected]>
> >
> > Introduce LSM_ORDER_LAST, to satisfy the requirement of LSMs needing to be
> > last, e.g. the 'integrity' LSM, without changing the kernel command line or
> > configuration.
> >
> > Also, set this order for the 'integrity' LSM. While not enforced, this is
> > the only LSM expected to use it.
> >
> > Similarly to LSM_ORDER_FIRST, LSMs with LSM_ORDER_LAST are always enabled
> > and put at the end of the LSM list.
>
> Since you are respinning this patchset anyway, I might make it clear
> that the LSM_ORDER_LAST LSMs are always enabled only when they are
> enabled at kernel configure/build time. Simply marking a LSM as
> LSM_ORDER_LAST does not mean you don't have to explicitly select the
> LSM in the rest of the Kconfig.
Ok, yes, better to clarify.
Thanks
Roberto
> > Finally, for LSM_ORDER_MUTABLE LSMs, set the found variable to true if an
> > LSM is found, regardless of its order. In this way, the kernel would not
> > wrongly report that the LSM is not built-in in the kernel if its order is
> > LSM_ORDER_LAST.
> >
> > Fixes: 79f7865d844c ("LSM: Introduce "lsm=" for boottime LSM selection")
> > Signed-off-by: Roberto Sassu <[email protected]>
> > ---
> > include/linux/lsm_hooks.h | 1 +
> > security/integrity/iint.c | 1 +
> > security/security.c | 12 +++++++++---
> > 3 files changed, 11 insertions(+), 3 deletions(-)
On Thu, 2023-03-09 at 17:04 -0500, Paul Moore wrote:
> On Thu, Mar 9, 2023 at 8:21 AM Mimi Zohar <[email protected]> wrote:
> > On Thu, 2023-03-09 at 09:54 +0100, Roberto Sassu wrote:
> > > From: Roberto Sassu <[email protected]>
> > >
> > > Introduce LSM_ORDER_LAST, to satisfy the requirement of LSMs needing to be
> > > last, e.g. the 'integrity' LSM, without changing the kernel command line or
> > > configuration.
> > >
> > > Also, set this order for the 'integrity' LSM. While not enforced, this is
> > > the only LSM expected to use it.
> > >
> > > Similarly to LSM_ORDER_FIRST, LSMs with LSM_ORDER_LAST are always enabled
> > > and put at the end of the LSM list.
> > >
> > > Finally, for LSM_ORDER_MUTABLE LSMs, set the found variable to true if an
> > > LSM is found, regardless of its order. In this way, the kernel would not
> > > wrongly report that the LSM is not built-in in the kernel if its order is
> > > LSM_ORDER_LAST.
> > >
> > > Fixes: 79f7865d844c ("LSM: Introduce "lsm=" for boottime LSM selection")
> > > Signed-off-by: Roberto Sassu <[email protected]>
> >
> > Signed-off-by: Mimi Zohar <[email protected]>
>
> Warning: procedural nitpicking ahead ...
>
> The 'Signed-off-by' tag is in reference to the DCO, which makes sense
> to add if you are a patch author or are merging a patch into a tree,
> but it doesn't make much sense as a ACK/thumbs-up; this is why we have
> the 'Acked-by' and 'Reviewed-by' tags. I generally read the
> 'Acked-by' tag as "I'm the one responsible for a chunk of code
> affected by this patch and I'm okay with this change" and the
> 'Reviewed-by' tag as "I looked at this patch and it looks like a good
> change to me". Perhaps surprisingly to some, while an 'Acked-by' is a
> requirement for merging in a lot of cases, I appreciate 'Reviewed-by'
> tags much more as it indicates the patch is getting some third-part
> eyeballs on it ... so all you lurkers on this list, if you're
> reviewing patches as they hit your inbox, don't be shy about posting
> your 'Reviewed-by' tag if your comfortable doing so, we all welcome
> the help :)
>
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
In this case, it was a bit unclear who actually was going to upstream
this patch set. It's better that you upstream it, but since this
affects subsequent IMA and EVM patches, please create a topic branch.
--
thanks,
Mimi
On Fri, Mar 10, 2023 at 8:39 AM Mimi Zohar <[email protected]> wrote:
> On Thu, 2023-03-09 at 17:04 -0500, Paul Moore wrote:
> > On Thu, Mar 9, 2023 at 8:21 AM Mimi Zohar <[email protected]> wrote:
> > > On Thu, 2023-03-09 at 09:54 +0100, Roberto Sassu wrote:
> > > > From: Roberto Sassu <[email protected]>
> > > >
> > > > Introduce LSM_ORDER_LAST, to satisfy the requirement of LSMs needing to be
> > > > last, e.g. the 'integrity' LSM, without changing the kernel command line or
> > > > configuration.
> > > >
> > > > Also, set this order for the 'integrity' LSM. While not enforced, this is
> > > > the only LSM expected to use it.
> > > >
> > > > Similarly to LSM_ORDER_FIRST, LSMs with LSM_ORDER_LAST are always enabled
> > > > and put at the end of the LSM list.
> > > >
> > > > Finally, for LSM_ORDER_MUTABLE LSMs, set the found variable to true if an
> > > > LSM is found, regardless of its order. In this way, the kernel would not
> > > > wrongly report that the LSM is not built-in in the kernel if its order is
> > > > LSM_ORDER_LAST.
> > > >
> > > > Fixes: 79f7865d844c ("LSM: Introduce "lsm=" for boottime LSM selection")
> > > > Signed-off-by: Roberto Sassu <[email protected]>
> > >
> > > Signed-off-by: Mimi Zohar <[email protected]>
> >
> > Warning: procedural nitpicking ahead ...
> >
> > The 'Signed-off-by' tag is in reference to the DCO, which makes sense
> > to add if you are a patch author or are merging a patch into a tree,
> > but it doesn't make much sense as a ACK/thumbs-up; this is why we have
> > the 'Acked-by' and 'Reviewed-by' tags. I generally read the
> > 'Acked-by' tag as "I'm the one responsible for a chunk of code
> > affected by this patch and I'm okay with this change" and the
> > 'Reviewed-by' tag as "I looked at this patch and it looks like a good
> > change to me". Perhaps surprisingly to some, while an 'Acked-by' is a
> > requirement for merging in a lot of cases, I appreciate 'Reviewed-by'
> > tags much more as it indicates the patch is getting some third-part
> > eyeballs on it ... so all you lurkers on this list, if you're
> > reviewing patches as they hit your inbox, don't be shy about posting
> > your 'Reviewed-by' tag if your comfortable doing so, we all welcome
> > the help :)
> >
> > https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
>
> In this case, it was a bit unclear who actually was going to upstream
> this patch set.
FWIW, I wasn't expecting to see your sign-off without a note that you
had merged it. Normally I would have expected either an acked-by or a
note that you had merged it, a sign-off without a merge notice seemed
a little odd to me so I thought I would mention the above :) No harm
either way, I just figured a little discussion on process might not be
a terrible idea to make sure we are all on the same page.
> It's better that you upstream it, but since this
> affects subsequent IMA and EVM patches, please create a topic branch.
I generally don't do topic branches for work that has been merged into
a -next or -stable branch. I prefer to limit topic branches to
special-cases where there is some value in keeping a central branch
for multiple people to coordinate while the patchset is still in
development; once a patchset has progressed far enough to be merged
into a -stable or -next branch I stop maintaining the topic branch.
In this particular case the changes to the IMA/EVM code looked very
minor, so I doubt there would be a significant merge conflict with the
IMA/EVM tree during this development cycle, but if you would prefer to
take this patchset via the IMA/EVM tree that is okay with me; just let
me know so I can ACK the two LSM-related patches (I'm going to review
the latest posting today).
As a bit of an aside, while this doesn't cover topic branches (once
again, I consider those special cases), when managing the LSM tree I
follow the process that is documented here:
https://github.com/LinuxSecurityModule/kernel/blob/main/README.md
[NOTE: the above GH repo is a read-only mirror of the canonical LSM
kernel.org repo, it just happens that GH does a better job rendering
txt]
The main LSM repo process "docs" / pointers can be found in the main
README or "about" page:
https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git/about
If people have suggestions for a different approach to managing the
LSM tree I'm always open to discussion.
--
paul-moore.com
On Fri, 2023-03-10 at 11:22 -0500, Paul Moore wrote:
> On Fri, Mar 10, 2023 at 8:39 AM Mimi Zohar <[email protected]> wrote:
> > On Thu, 2023-03-09 at 17:04 -0500, Paul Moore wrote:
> > > On Thu, Mar 9, 2023 at 8:21 AM Mimi Zohar <[email protected]> wrote:
> > > > On Thu, 2023-03-09 at 09:54 +0100, Roberto Sassu wrote:
> > > > > From: Roberto Sassu <[email protected]>
> > > > >
> > > > > Introduce LSM_ORDER_LAST, to satisfy the requirement of LSMs needing to be
> > > > > last, e.g. the 'integrity' LSM, without changing the kernel command line or
> > > > > configuration.
> > > > >
> > > > > Also, set this order for the 'integrity' LSM. While not enforced, this is
> > > > > the only LSM expected to use it.
> > > > >
> > > > > Similarly to LSM_ORDER_FIRST, LSMs with LSM_ORDER_LAST are always enabled
> > > > > and put at the end of the LSM list.
> > > > >
> > > > > Finally, for LSM_ORDER_MUTABLE LSMs, set the found variable to true if an
> > > > > LSM is found, regardless of its order. In this way, the kernel would not
> > > > > wrongly report that the LSM is not built-in in the kernel if its order is
> > > > > LSM_ORDER_LAST.
> > > > >
> > > > > Fixes: 79f7865d844c ("LSM: Introduce "lsm=" for boottime LSM selection")
> > > > > Signed-off-by: Roberto Sassu <[email protected]>
> > > >
> > > > Signed-off-by: Mimi Zohar <[email protected]>
> > >
> > > Warning: procedural nitpicking ahead ...
> > >
> > > The 'Signed-off-by' tag is in reference to the DCO, which makes sense
> > > to add if you are a patch author or are merging a patch into a tree,
> > > but it doesn't make much sense as a ACK/thumbs-up; this is why we have
> > > the 'Acked-by' and 'Reviewed-by' tags. I generally read the
> > > 'Acked-by' tag as "I'm the one responsible for a chunk of code
> > > affected by this patch and I'm okay with this change" and the
> > > 'Reviewed-by' tag as "I looked at this patch and it looks like a good
> > > change to me". Perhaps surprisingly to some, while an 'Acked-by' is a
> > > requirement for merging in a lot of cases, I appreciate 'Reviewed-by'
> > > tags much more as it indicates the patch is getting some third-part
> > > eyeballs on it ... so all you lurkers on this list, if you're
> > > reviewing patches as they hit your inbox, don't be shy about posting
> > > your 'Reviewed-by' tag if your comfortable doing so, we all welcome
> > > the help :)
> > >
> > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
> >
> > In this case, it was a bit unclear who actually was going to upstream
> > this patch set.
>
> FWIW, I wasn't expecting to see your sign-off without a note that you
> had merged it. Normally I would have expected either an acked-by or a
> note that you had merged it, a sign-off without a merge notice seemed
> a little odd to me so I thought I would mention the above :) No harm
> either way, I just figured a little discussion on process might not be
> a terrible idea to make sure we are all on the same page.
>
> > It's better that you upstream it, but since this
> > affects subsequent IMA and EVM patches, please create a topic branch.
>
> I generally don't do topic branches for work that has been merged into
> a -next or -stable branch. I prefer to limit topic branches to
> special-cases where there is some value in keeping a central branch
> for multiple people to coordinate while the patchset is still in
> development; once a patchset has progressed far enough to be merged
> into a -stable or -next branch I stop maintaining the topic branch.
>
> In this particular case the changes to the IMA/EVM code looked very
> minor, so I doubt there would be a significant merge conflict with the
> IMA/EVM tree during this development cycle, but if you would prefer to
> take this patchset via the IMA/EVM tree that is okay with me; just let
> me know so I can ACK the two LSM-related patches (I'm going to review
> the latest posting today).
Probably it would be beneficial if you carry this patch set, so that
the next 'evm: Do HMAC of multiple per LSM xattrs for new inodes', and
'security: Move IMA and EVM to the LSM infrastructure' could be applied
on top (assuming that we are able to finish within this cycle).
Thanks
Roberto
> As a bit of an aside, while this doesn't cover topic branches (once
> again, I consider those special cases), when managing the LSM tree I
> follow the process that is documented here:
>
> https://github.com/LinuxSecurityModule/kernel/blob/main/README.md
>
> [NOTE: the above GH repo is a read-only mirror of the canonical LSM
> kernel.org repo, it just happens that GH does a better job rendering
> txt]
>
> The main LSM repo process "docs" / pointers can be found in the main
> README or "about" page:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git/about
>
> If people have suggestions for a different approach to managing the
> LSM tree I'm always open to discussion.
>
On Fri, 2023-03-10 at 17:33 +0100, Roberto Sassu wrote:
> On Fri, 2023-03-10 at 11:22 -0500, Paul Moore wrote:
> > On Fri, Mar 10, 2023 at 8:39 AM Mimi Zohar <[email protected]> wrote:
> > > On Thu, 2023-03-09 at 17:04 -0500, Paul Moore wrote:
> > > > On Thu, Mar 9, 2023 at 8:21 AM Mimi Zohar <[email protected]> wrote:
> > > > > On Thu, 2023-03-09 at 09:54 +0100, Roberto Sassu wrote:
> > > > > > From: Roberto Sassu <[email protected]>
> > > > > >
> > > > > > Introduce LSM_ORDER_LAST, to satisfy the requirement of LSMs needing to be
> > > > > > last, e.g. the 'integrity' LSM, without changing the kernel command line or
> > > > > > configuration.
> > > > > >
> > > > > > Also, set this order for the 'integrity' LSM. While not enforced, this is
> > > > > > the only LSM expected to use it.
> > > > > >
> > > > > > Similarly to LSM_ORDER_FIRST, LSMs with LSM_ORDER_LAST are always enabled
> > > > > > and put at the end of the LSM list.
> > > > > >
> > > > > > Finally, for LSM_ORDER_MUTABLE LSMs, set the found variable to true if an
> > > > > > LSM is found, regardless of its order. In this way, the kernel would not
> > > > > > wrongly report that the LSM is not built-in in the kernel if its order is
> > > > > > LSM_ORDER_LAST.
> > > > > >
> > > > > > Fixes: 79f7865d844c ("LSM: Introduce "lsm=" for boottime LSM selection")
> > > > > > Signed-off-by: Roberto Sassu <[email protected]>
> > > > >
> > > > > Signed-off-by: Mimi Zohar <[email protected]>
> > > >
> > > > Warning: procedural nitpicking ahead ...
> > > >
> > > > The 'Signed-off-by' tag is in reference to the DCO, which makes sense
> > > > to add if you are a patch author or are merging a patch into a tree,
> > > > but it doesn't make much sense as a ACK/thumbs-up; this is why we have
> > > > the 'Acked-by' and 'Reviewed-by' tags. I generally read the
> > > > 'Acked-by' tag as "I'm the one responsible for a chunk of code
> > > > affected by this patch and I'm okay with this change" and the
> > > > 'Reviewed-by' tag as "I looked at this patch and it looks like a good
> > > > change to me". Perhaps surprisingly to some, while an 'Acked-by' is a
> > > > requirement for merging in a lot of cases, I appreciate 'Reviewed-by'
> > > > tags much more as it indicates the patch is getting some third-part
> > > > eyeballs on it ... so all you lurkers on this list, if you're
> > > > reviewing patches as they hit your inbox, don't be shy about posting
> > > > your 'Reviewed-by' tag if your comfortable doing so, we all welcome
> > > > the help :)
> > > >
> > > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
> > >
> > > In this case, it was a bit unclear who actually was going to upstream
> > > this patch set.
> >
> > FWIW, I wasn't expecting to see your sign-off without a note that you
> > had merged it. Normally I would have expected either an acked-by or a
> > note that you had merged it, a sign-off without a merge notice seemed
> > a little odd to me so I thought I would mention the above :) No harm
> > either way, I just figured a little discussion on process might not be
> > a terrible idea to make sure we are all on the same page.
> >
> > > It's better that you upstream it, but since this
> > > affects subsequent IMA and EVM patches, please create a topic branch.
> >
> > I generally don't do topic branches for work that has been merged into
> > a -next or -stable branch. I prefer to limit topic branches to
> > special-cases where there is some value in keeping a central branch
> > for multiple people to coordinate while the patchset is still in
> > development; once a patchset has progressed far enough to be merged
> > into a -stable or -next branch I stop maintaining the topic branch.
I'm definitely not the expert in this, but topic branches normally need
to remain around until they make it into a release or an -rc, not
-next.
> >
> > In this particular case the changes to the IMA/EVM code looked very
> > minor, so I doubt there would be a significant merge conflict with the
> > IMA/EVM tree during this development cycle, but if you would prefer to
> > take this patchset via the IMA/EVM tree that is okay with me; just let
> > me know so I can ACK the two LSM-related patches (I'm going to review
> > the latest posting today).
>
> Probably it would be beneficial if you carry this patch set, so that
> the next 'evm: Do HMAC of multiple per LSM xattrs for new inodes', and
> 'security: Move IMA and EVM to the LSM infrastructure' could be applied
> on top (assuming that we are able to finish within this cycle).
That's fine.
>
> > As a bit of an aside, while this doesn't cover topic branches (once
> > again, I consider those special cases), when managing the LSM tree I
> > follow the process that is documented here:
> >
> > https://github.com/LinuxSecurityModule/kernel/blob/main/README.md
> >
> > [NOTE: the above GH repo is a read-only mirror of the canonical LSM
> > kernel.org repo, it just happens that GH does a better job rendering
> > txt]
> >
> > The main LSM repo process "docs" / pointers can be found in the main
> > README or "about" page:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git/about
> >
> > If people have suggestions for a different approach to managing the
> > LSM tree I'm always open to discussion.
Thank you for the pointer. Nicely written.
--
thanks,
Mimi