[v3,1/3] security: Introduce LSM_ORDER_LAST and set it for the integrity LSM

Commit Message

Roberto Sassu March 9, 2023, 8:54 a.m. UTC

From: Roberto Sassu <[e-mail]>

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 <[e-mail]>
---
 include/linux/lsm_hooks.h |  1 +
 security/integrity/iint.c |  1 +
 security/security.c       | 12 +++++++++---
 3 files changed, 11 insertions(+), 3 deletions(-)

Comments

Mimi Zohar March 9, 2023, 1:20 p.m. UTC | #1

On Thu, 2023-03-09 at 09:54 +0100, Roberto Sassu wrote:
> From: Roberto Sassu <[e-mail]>
> 
> 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 <[e-mail]>

Signed-off-by: Mimi Zohar <[e-mail]>

Paul Moore March 9, 2023, 10:04 p.m. UTC | #2

On Thu, Mar 9, 2023 at 8:21 AM Mimi Zohar <[e-mail]> wrote:
> On Thu, 2023-03-09 at 09:54 +0100, Roberto Sassu wrote:
> > From: Roberto Sassu <[e-mail]>
> >
> > 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 <[e-mail]>
>
> Signed-off-by: Mimi Zohar <[e-mail]>

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 March 9, 2023, 11:44 p.m. UTC | #3

On Thu, Mar 9, 2023 at 3:55 AM Roberto Sassu
<[e-mail]> wrote:
>
> From: Roberto Sassu <[e-mail]>
>
> 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 <[e-mail]>
> ---
>  include/linux/lsm_hooks.h |  1 +
>  security/integrity/iint.c |  1 +
>  security/security.c       | 12 +++++++++---
>  3 files changed, 11 insertions(+), 3 deletions(-)

Roberto Sassu March 10, 2023, 7:57 a.m. UTC | #4

On Thu, 2023-03-09 at 18:44 -0500, Paul Moore wrote:
> On Thu, Mar 9, 2023 at 3:55 AM Roberto Sassu
> <[e-mail]> wrote:
> > From: Roberto Sassu <[e-mail]>
> > 
> > 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 <[e-mail]>
> > ---
> >  include/linux/lsm_hooks.h |  1 +
> >  security/integrity/iint.c |  1 +
> >  security/security.c       | 12 +++++++++---
> >  3 files changed, 11 insertions(+), 3 deletions(-)

Mimi Zohar March 10, 2023, 1:38 p.m. UTC | #5

On Thu, 2023-03-09 at 17:04 -0500, Paul Moore wrote:
> On Thu, Mar 9, 2023 at 8:21 AM Mimi Zohar <[e-mail]> wrote:
> > On Thu, 2023-03-09 at 09:54 +0100, Roberto Sassu wrote:
> > > From: Roberto Sassu <[e-mail]>
> > >
> > > 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 <[e-mail]>
> >
> > Signed-off-by: Mimi Zohar <[e-mail]>
> 
> 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.

Paul Moore March 10, 2023, 4:22 p.m. UTC | #6

On Fri, Mar 10, 2023 at 8:39 AM Mimi Zohar <[e-mail]> wrote:
> On Thu, 2023-03-09 at 17:04 -0500, Paul Moore wrote:
> > On Thu, Mar 9, 2023 at 8:21 AM Mimi Zohar <[e-mail]> wrote:
> > > On Thu, 2023-03-09 at 09:54 +0100, Roberto Sassu wrote:
> > > > From: Roberto Sassu <[e-mail]>
> > > >
> > > > 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 <[e-mail]>
> > >
> > > Signed-off-by: Mimi Zohar <[e-mail]>
> >
> > 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.

Roberto Sassu March 10, 2023, 4:33 p.m. UTC | #7

On Fri, 2023-03-10 at 11:22 -0500, Paul Moore wrote:
> On Fri, Mar 10, 2023 at 8:39 AM Mimi Zohar <[e-mail]> wrote:
> > On Thu, 2023-03-09 at 17:04 -0500, Paul Moore wrote:
> > > On Thu, Mar 9, 2023 at 8:21 AM Mimi Zohar <[e-mail]> wrote:
> > > > On Thu, 2023-03-09 at 09:54 +0100, Roberto Sassu wrote:
> > > > > From: Roberto Sassu <[e-mail]>
> > > > > 
> > > > > 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 <[e-mail]>
> > > > 
> > > > Signed-off-by: Mimi Zohar <[e-mail]>
> > > 
> > > 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.
>

Mimi Zohar March 10, 2023, 7:59 p.m. UTC | #8

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 <[e-mail]> wrote:
> > > On Thu, 2023-03-09 at 17:04 -0500, Paul Moore wrote:
> > > > On Thu, Mar 9, 2023 at 8:21 AM Mimi Zohar <[e-mail]> wrote:
> > > > > On Thu, 2023-03-09 at 09:54 +0100, Roberto Sassu wrote:
> > > > > > From: Roberto Sassu <[e-mail]>
> > > > > > 
> > > > > > 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 <[e-mail]>
> > > > > 
> > > > > Signed-off-by: Mimi Zohar <[e-mail]>
> > > > 
> > > > 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.

Patch

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))