* [PATCH v3 0/3] security: Always enable integrity LSM @ 2023-03-09 8:54 Roberto Sassu 2023-03-09 8:54 ` [PATCH v3 1/3] security: Introduce LSM_ORDER_LAST and set it for the " Roberto Sassu ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Roberto Sassu @ 2023-03-09 8:54 UTC (permalink / raw) To: zohar, dmitry.kasatkin, paul, jmorris, serge, mic Cc: linux-integrity, linux-security-module, bpf, linux-kernel, keescook, Roberto Sassu From: Roberto Sassu <roberto.sassu@huawei.com> 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH v3 1/3] security: Introduce LSM_ORDER_LAST and set it for the integrity LSM 2023-03-09 8:54 [PATCH v3 0/3] security: Always enable integrity LSM Roberto Sassu @ 2023-03-09 8:54 ` Roberto Sassu 2023-03-09 13:20 ` Mimi Zohar 2023-03-09 23:44 ` Paul Moore 2023-03-09 8:54 ` [PATCH v3 2/3] Revert "integrity: double check iint_cache was initialized" Roberto Sassu 2023-03-09 8:54 ` [PATCH v3 3/3] security: Remove integrity from the LSM list in Kconfig Roberto Sassu 2 siblings, 2 replies; 16+ messages in thread From: Roberto Sassu @ 2023-03-09 8:54 UTC (permalink / raw) To: zohar, dmitry.kasatkin, paul, jmorris, serge, mic Cc: linux-integrity, linux-security-module, bpf, linux-kernel, keescook, Roberto Sassu From: Roberto Sassu <roberto.sassu@huawei.com> 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 <roberto.sassu@huawei.com> --- 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 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH v3 1/3] security: Introduce LSM_ORDER_LAST and set it for the integrity LSM 2023-03-09 8:54 ` [PATCH v3 1/3] security: Introduce LSM_ORDER_LAST and set it for the " Roberto Sassu @ 2023-03-09 13:20 ` Mimi Zohar 2023-03-09 22:04 ` Paul Moore 2023-03-09 23:44 ` Paul Moore 1 sibling, 1 reply; 16+ messages in thread From: Mimi Zohar @ 2023-03-09 13:20 UTC (permalink / raw) To: Roberto Sassu, dmitry.kasatkin, paul, jmorris, serge, mic Cc: linux-integrity, linux-security-module, bpf, linux-kernel, keescook, Roberto Sassu On Thu, 2023-03-09 at 09:54 +0100, Roberto Sassu wrote: > From: Roberto Sassu <roberto.sassu@huawei.com> > > 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 <roberto.sassu@huawei.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v3 1/3] security: Introduce LSM_ORDER_LAST and set it for the integrity LSM 2023-03-09 13:20 ` Mimi Zohar @ 2023-03-09 22:04 ` Paul Moore 2023-03-10 13:38 ` Mimi Zohar 0 siblings, 1 reply; 16+ messages in thread From: Paul Moore @ 2023-03-09 22:04 UTC (permalink / raw) To: Mimi Zohar Cc: Roberto Sassu, dmitry.kasatkin, jmorris, serge, mic, linux-integrity, linux-security-module, bpf, linux-kernel, keescook, Roberto Sassu On Thu, Mar 9, 2023 at 8:21 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > On Thu, 2023-03-09 at 09:54 +0100, Roberto Sassu wrote: > > From: Roberto Sassu <roberto.sassu@huawei.com> > > > > 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 <roberto.sassu@huawei.com> > > Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v3 1/3] security: Introduce LSM_ORDER_LAST and set it for the integrity LSM 2023-03-09 22:04 ` Paul Moore @ 2023-03-10 13:38 ` Mimi Zohar 2023-03-10 16:22 ` Paul Moore 0 siblings, 1 reply; 16+ messages in thread From: Mimi Zohar @ 2023-03-10 13:38 UTC (permalink / raw) To: Paul Moore Cc: Roberto Sassu, dmitry.kasatkin, jmorris, serge, mic, linux-integrity, linux-security-module, bpf, linux-kernel, keescook, Roberto Sassu On Thu, 2023-03-09 at 17:04 -0500, Paul Moore wrote: > On Thu, Mar 9, 2023 at 8:21 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > On Thu, 2023-03-09 at 09:54 +0100, Roberto Sassu wrote: > > > From: Roberto Sassu <roberto.sassu@huawei.com> > > > > > > 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 <roberto.sassu@huawei.com> > > > > Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> > > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v3 1/3] security: Introduce LSM_ORDER_LAST and set it for the integrity LSM 2023-03-10 13:38 ` Mimi Zohar @ 2023-03-10 16:22 ` Paul Moore 2023-03-10 16:33 ` Roberto Sassu 0 siblings, 1 reply; 16+ messages in thread From: Paul Moore @ 2023-03-10 16:22 UTC (permalink / raw) To: Mimi Zohar Cc: Roberto Sassu, dmitry.kasatkin, jmorris, serge, mic, linux-integrity, linux-security-module, bpf, linux-kernel, keescook, Roberto Sassu On Fri, Mar 10, 2023 at 8:39 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > On Thu, 2023-03-09 at 17:04 -0500, Paul Moore wrote: > > On Thu, Mar 9, 2023 at 8:21 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > On Thu, 2023-03-09 at 09:54 +0100, Roberto Sassu wrote: > > > > From: Roberto Sassu <roberto.sassu@huawei.com> > > > > > > > > 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 <roberto.sassu@huawei.com> > > > > > > Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> > > > > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v3 1/3] security: Introduce LSM_ORDER_LAST and set it for the integrity LSM 2023-03-10 16:22 ` Paul Moore @ 2023-03-10 16:33 ` Roberto Sassu 2023-03-10 19:59 ` Mimi Zohar 0 siblings, 1 reply; 16+ messages in thread From: Roberto Sassu @ 2023-03-10 16:33 UTC (permalink / raw) To: Paul Moore, Mimi Zohar Cc: dmitry.kasatkin, jmorris, serge, mic, linux-integrity, linux-security-module, bpf, linux-kernel, keescook, Roberto Sassu On Fri, 2023-03-10 at 11:22 -0500, Paul Moore wrote: > On Fri, Mar 10, 2023 at 8:39 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > On Thu, 2023-03-09 at 17:04 -0500, Paul Moore wrote: > > > On Thu, Mar 9, 2023 at 8:21 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > On Thu, 2023-03-09 at 09:54 +0100, Roberto Sassu wrote: > > > > > From: Roberto Sassu <roberto.sassu@huawei.com> > > > > > > > > > > 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 <roberto.sassu@huawei.com> > > > > > > > > Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> > > > > > > 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. > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v3 1/3] security: Introduce LSM_ORDER_LAST and set it for the integrity LSM 2023-03-10 16:33 ` Roberto Sassu @ 2023-03-10 19:59 ` Mimi Zohar 0 siblings, 0 replies; 16+ messages in thread From: Mimi Zohar @ 2023-03-10 19:59 UTC (permalink / raw) To: Roberto Sassu, Paul Moore Cc: dmitry.kasatkin, jmorris, serge, mic, linux-integrity, linux-security-module, bpf, linux-kernel, keescook, Roberto Sassu 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 <zohar@linux.ibm.com> wrote: > > > On Thu, 2023-03-09 at 17:04 -0500, Paul Moore wrote: > > > > On Thu, Mar 9, 2023 at 8:21 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > > On Thu, 2023-03-09 at 09:54 +0100, Roberto Sassu wrote: > > > > > > From: Roberto Sassu <roberto.sassu@huawei.com> > > > > > > > > > > > > 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 <roberto.sassu@huawei.com> > > > > > > > > > > Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> > > > > > > > > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v3 1/3] security: Introduce LSM_ORDER_LAST and set it for the integrity LSM 2023-03-09 8:54 ` [PATCH v3 1/3] security: Introduce LSM_ORDER_LAST and set it for the " Roberto Sassu 2023-03-09 13:20 ` Mimi Zohar @ 2023-03-09 23:44 ` Paul Moore 2023-03-10 7:57 ` Roberto Sassu 1 sibling, 1 reply; 16+ messages in thread From: Paul Moore @ 2023-03-09 23:44 UTC (permalink / raw) To: Roberto Sassu Cc: zohar, dmitry.kasatkin, jmorris, serge, mic, linux-integrity, linux-security-module, bpf, linux-kernel, keescook, Roberto Sassu On Thu, Mar 9, 2023 at 3:55 AM Roberto Sassu <roberto.sassu@huaweicloud.com> wrote: > > From: Roberto Sassu <roberto.sassu@huawei.com> > > 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 <roberto.sassu@huawei.com> > --- > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v3 1/3] security: Introduce LSM_ORDER_LAST and set it for the integrity LSM 2023-03-09 23:44 ` Paul Moore @ 2023-03-10 7:57 ` Roberto Sassu 0 siblings, 0 replies; 16+ messages in thread From: Roberto Sassu @ 2023-03-10 7:57 UTC (permalink / raw) To: Paul Moore Cc: zohar, dmitry.kasatkin, jmorris, serge, mic, linux-integrity, linux-security-module, bpf, linux-kernel, keescook, Roberto Sassu On Thu, 2023-03-09 at 18:44 -0500, Paul Moore wrote: > On Thu, Mar 9, 2023 at 3:55 AM Roberto Sassu > <roberto.sassu@huaweicloud.com> wrote: > > From: Roberto Sassu <roberto.sassu@huawei.com> > > > > 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 <roberto.sassu@huawei.com> > > --- > > include/linux/lsm_hooks.h | 1 + > > security/integrity/iint.c | 1 + > > security/security.c | 12 +++++++++--- > > 3 files changed, 11 insertions(+), 3 deletions(-) ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH v3 2/3] Revert "integrity: double check iint_cache was initialized" 2023-03-09 8:54 [PATCH v3 0/3] security: Always enable integrity LSM Roberto Sassu 2023-03-09 8:54 ` [PATCH v3 1/3] security: Introduce LSM_ORDER_LAST and set it for the " Roberto Sassu @ 2023-03-09 8:54 ` Roberto Sassu 2023-03-09 13:20 ` Mimi Zohar 2023-03-09 8:54 ` [PATCH v3 3/3] security: Remove integrity from the LSM list in Kconfig Roberto Sassu 2 siblings, 1 reply; 16+ messages in thread From: Roberto Sassu @ 2023-03-09 8:54 UTC (permalink / raw) To: zohar, dmitry.kasatkin, paul, jmorris, serge, mic Cc: linux-integrity, linux-security-module, bpf, linux-kernel, keescook, Roberto Sassu From: Roberto Sassu <roberto.sassu@huawei.com> 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 <roberto.sassu@huawei.com> --- 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 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH v3 2/3] Revert "integrity: double check iint_cache was initialized" 2023-03-09 8:54 ` [PATCH v3 2/3] Revert "integrity: double check iint_cache was initialized" Roberto Sassu @ 2023-03-09 13:20 ` Mimi Zohar 0 siblings, 0 replies; 16+ messages in thread From: Mimi Zohar @ 2023-03-09 13:20 UTC (permalink / raw) To: Roberto Sassu, dmitry.kasatkin, paul, jmorris, serge, mic Cc: linux-integrity, linux-security-module, bpf, linux-kernel, keescook, Roberto Sassu On Thu, 2023-03-09 at 09:54 +0100, Roberto Sassu wrote: > From: Roberto Sassu <roberto.sassu@huawei.com> > > 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 <roberto.sassu@huawei.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH v3 3/3] security: Remove integrity from the LSM list in Kconfig 2023-03-09 8:54 [PATCH v3 0/3] security: Always enable integrity LSM Roberto Sassu 2023-03-09 8:54 ` [PATCH v3 1/3] security: Introduce LSM_ORDER_LAST and set it for the " Roberto Sassu 2023-03-09 8:54 ` [PATCH v3 2/3] Revert "integrity: double check iint_cache was initialized" Roberto Sassu @ 2023-03-09 8:54 ` Roberto Sassu 2023-03-09 13:20 ` Mimi Zohar 2023-03-09 23:45 ` Paul Moore 2 siblings, 2 replies; 16+ messages in thread From: Roberto Sassu @ 2023-03-09 8:54 UTC (permalink / raw) To: zohar, dmitry.kasatkin, paul, jmorris, serge, mic Cc: linux-integrity, linux-security-module, bpf, linux-kernel, keescook, Roberto Sassu From: Roberto Sassu <roberto.sassu@huawei.com> 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 <roberto.sassu@huawei.com> --- 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 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH v3 3/3] security: Remove integrity from the LSM list in Kconfig 2023-03-09 8:54 ` [PATCH v3 3/3] security: Remove integrity from the LSM list in Kconfig Roberto Sassu @ 2023-03-09 13:20 ` Mimi Zohar 2023-03-09 13:29 ` Roberto Sassu 2023-03-09 23:45 ` Paul Moore 1 sibling, 1 reply; 16+ messages in thread From: Mimi Zohar @ 2023-03-09 13:20 UTC (permalink / raw) To: Roberto Sassu, dmitry.kasatkin, paul, jmorris, serge, mic Cc: linux-integrity, linux-security-module, bpf, linux-kernel, keescook, Roberto Sassu On Thu, 2023-03-09 at 09:54 +0100, Roberto Sassu wrote: > From: Roberto Sassu <roberto.sassu@huawei.com> > > 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 <roberto.sassu@huawei.com> > --- > 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 <zohar@linux.ibm.com> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v3 3/3] security: Remove integrity from the LSM list in Kconfig 2023-03-09 13:20 ` Mimi Zohar @ 2023-03-09 13:29 ` Roberto Sassu 0 siblings, 0 replies; 16+ messages in thread From: Roberto Sassu @ 2023-03-09 13:29 UTC (permalink / raw) To: Mimi Zohar, dmitry.kasatkin, paul, jmorris, serge, mic Cc: linux-integrity, linux-security-module, bpf, linux-kernel, keescook, Roberto Sassu 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 <roberto.sassu@huawei.com> > > > > 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 <roberto.sassu@huawei.com> > > --- > > 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 <zohar@linux.ibm.com> > > > > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v3 3/3] security: Remove integrity from the LSM list in Kconfig 2023-03-09 8:54 ` [PATCH v3 3/3] security: Remove integrity from the LSM list in Kconfig Roberto Sassu 2023-03-09 13:20 ` Mimi Zohar @ 2023-03-09 23:45 ` Paul Moore 1 sibling, 0 replies; 16+ messages in thread From: Paul Moore @ 2023-03-09 23:45 UTC (permalink / raw) To: Roberto Sassu Cc: zohar, dmitry.kasatkin, jmorris, serge, mic, linux-integrity, linux-security-module, bpf, linux-kernel, keescook, Roberto Sassu On Thu, Mar 9, 2023 at 3:55 AM Roberto Sassu <roberto.sassu@huaweicloud.com> wrote: > > From: Roberto Sassu <roberto.sassu@huawei.com> > > 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 <roberto.sassu@huawei.com> > --- > security/Kconfig | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) -- paul-moore.com ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2023-03-10 19:59 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-03-09 8:54 [PATCH v3 0/3] security: Always enable integrity LSM Roberto Sassu 2023-03-09 8:54 ` [PATCH v3 1/3] security: Introduce LSM_ORDER_LAST and set it for the " Roberto Sassu 2023-03-09 13:20 ` Mimi Zohar 2023-03-09 22:04 ` Paul Moore 2023-03-10 13:38 ` Mimi Zohar 2023-03-10 16:22 ` Paul Moore 2023-03-10 16:33 ` Roberto Sassu 2023-03-10 19:59 ` Mimi Zohar 2023-03-09 23:44 ` Paul Moore 2023-03-10 7:57 ` Roberto Sassu 2023-03-09 8:54 ` [PATCH v3 2/3] Revert "integrity: double check iint_cache was initialized" Roberto Sassu 2023-03-09 13:20 ` Mimi Zohar 2023-03-09 8:54 ` [PATCH v3 3/3] security: Remove integrity from the LSM list in Kconfig Roberto Sassu 2023-03-09 13:20 ` Mimi Zohar 2023-03-09 13:29 ` Roberto Sassu 2023-03-09 23:45 ` Paul Moore
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).