* Re: [syzbot] Monthly lsm report (Apr 2026)
From: Jarkko Sakkinen @ 2026-04-15 2:51 UTC (permalink / raw)
To: Paul Moore
Cc: David Howells, linux-kernel, linux-security-module,
syzkaller-bugs, syzbot
In-Reply-To: <CAHC9VhS2AaRwAQw1hNcpuGdFSOL7Li9PavKtU7eW-w8eMOFuKA@mail.gmail.com>
On Tue, Apr 14, 2026 at 10:02:13AM -0400, Paul Moore wrote:
> On Tue, Apr 14, 2026 at 2:48 AM syzbot
> <syzbot+liste5004e02dae137bbd339@syzkaller.appspotmail.com> wrote:
> >
> > Hello lsm maintainers/developers,
> >
> > This is a 31-day syzbot report for the lsm subsystem.
> > All related reports/information can be found at:
> > https://syzkaller.appspot.com/upstream/s/lsm
> >
> > During the period, 0 new issues were detected and 0 were fixed.
> > In total, 3 issues are still open and 45 have already been fixed.
> >
> > Some of the still happening issues:
> >
> > Ref Crashes Repro Title
> > <1> 95 Yes INFO: task hung in process_measurement (3)
> > https://syzkaller.appspot.com/bug?extid=cb9e66807bcb882cd0c5
> > <2> 68 Yes possible deadlock in keyring_clear (3)
> > https://syzkaller.appspot.com/bug?extid=f55b043dacf43776b50c
>
> Jarkko, David,
>
> Do we have a fix for the keyring_clear() issue, or is it not a real problem?
I'll take analyzing this to my todo list for next week (post first PR).
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] trusted-keys: move pr_fmt out of trusted-type.h
From: Jarkko Sakkinen @ 2026-04-15 2:44 UTC (permalink / raw)
To: Ahmad Fatoum
Cc: Marco Felsch, Josh Snyder, James Bottomley, Mimi Zohar,
David Howells, Pengutronix Kernel Team, Paul Moore, James Morris,
Serge E. Hallyn, David Gstir, sigma star Kernel Team,
Srish Srinivasan, Nayna Jain, Sumit Garg, linux-security-module,
linux-integrity, keyrings, linux-kernel
In-Reply-To: <20e9f021-f6b3-4e19-9e1b-93b1e00eb803@pengutronix.de>
On Mon, Apr 13, 2026 at 01:03:30PM +0200, Ahmad Fatoum wrote:
> Hi,
>
> On 4/13/26 1:01 PM, Marco Felsch wrote:
> > Hi Josh,
> >
> > On 26-04-11, Josh Snyder wrote:
> >> Defining pr_fmt in a widely-included header leaks the "trusted_key: "
> >> prefix into every translation unit that transitively includes
> >> <keys/trusted-type.h>. dm-crypt, for example, ends up printing
> >>
> >> trusted_key: device-mapper: crypt: dm-10: INTEGRITY AEAD ERROR ...
> >>
> >> dm-crypt began including <keys/trusted-type.h> in commit 363880c4eb36
> >> ("dm crypt: support using trusted keys"), which predates the pr_fmt
> >> addition, so the regression has been live from the moment the header
> >> gained its own pr_fmt definition.
> >>
> >> Move the pr_fmt definition into the trusted-keys source files that
> >> actually want the prefix.
> >>
> >> Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework")
> >> Assisted-by: Claude:claude-opus-4-6
> >> Signed-off-by: Josh Snyder <josh@code406.com>
> >> ---
> >> include/keys/trusted-type.h | 6 ------
> >> security/keys/trusted-keys/trusted_caam.c | 2 ++
> >> security/keys/trusted-keys/trusted_core.c | 2 ++
> >> security/keys/trusted-keys/trusted_dcp.c | 2 ++
> >> security/keys/trusted-keys/trusted_pkwm.c | 2 ++
> >> security/keys/trusted-keys/trusted_tpm1.c | 2 ++
> >> security/keys/trusted-keys/trusted_tpm2.c | 2 ++
> >> 7 files changed, 12 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
> >> index 03527162613f7..54da1f174aeab 100644
> >> --- a/include/keys/trusted-type.h
> >> +++ b/include/keys/trusted-type.h
> >> @@ -11,12 +11,6 @@
> >> #include <linux/rcupdate.h>
> >> #include <linux/tpm.h>
> >>
> >> -#ifdef pr_fmt
> >> -#undef pr_fmt
> >> -#endif
> >> -
> >> -#define pr_fmt(fmt) "trusted_key: " fmt
> >> -
> >> #define MIN_KEY_SIZE 32
> >> #define MAX_KEY_SIZE 128
> >> #if IS_ENABLED(CONFIG_TRUSTED_KEYS_PKWM)
> >> diff --git a/security/keys/trusted-keys/trusted_caam.c b/security/keys/trusted-keys/trusted_caam.c
> >> index 601943ce0d60f..a31fd89c0e5c5 100644
> >> --- a/security/keys/trusted-keys/trusted_caam.c
> >> +++ b/security/keys/trusted-keys/trusted_caam.c
> >> @@ -4,6 +4,8 @@
> >> * Copyright 2025 NXP
> >> */
> >>
> >> +#define pr_fmt(fmt) "trusted_key: " fmt
> >
> > Can we adapt this patch further to include the trusted-key type as well?
> > E.g. 'trusted_key-caam'.
>
> Agreed, if we move it into the individual files, we can use the occasion
> to make it a bit more descriptive.
>
> I would suggest "trusted_key: caam: ", so the prefix stays the same.
>
> Cheers,
> Ahmad
+1
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v2 2/2] integrity: Add support for sigv3 verification using ML-DSA keys
From: Mimi Zohar @ 2026-04-15 2:01 UTC (permalink / raw)
To: Stefan Berger, linux-integrity, linux-security-module
Cc: linux-kernel, roberto.sassu, ebiggers
In-Reply-To: <20260408174154.139606-3-stefanb@linux.ibm.com>
On Wed, 2026-04-08 at 13:41 -0400, Stefan Berger wrote:
> Add support for sigv3 signature verification using ML-DSA in pure mode.
> When a sigv3 signature is verified, first check whether the key to use
> for verification is an ML-DSA key and therefore uses a hashless signature
> verification scheme. The hashless signature verification method uses the
> ima_file_id structure directly for signature verification rather than
> its digest.
>
> Suggested-by: Eric Biggers <ebiggers@kernel.org>
> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
>
Thanks, Stefan.
> ---
> v2: Set hash_algo in public_key_signature to "none"
> ---
> security/integrity/digsig_asymmetric.c | 84 ++++++++++++++++++++++++--
> 1 file changed, 79 insertions(+), 5 deletions(-)
>
> diff --git a/security/integrity/digsig_asymmetric.c b/security/integrity/digsig_asymmetric.c
> index e29ed73f15cd..c80cb2b117a6 100644
> --- a/security/integrity/digsig_asymmetric.c
> +++ b/security/integrity/digsig_asymmetric.c
> @@ -190,17 +190,91 @@ static int calc_file_id_hash(enum evm_ima_xattr_type type,
> return rc;
> }
>
> +/*
kernel-doc starts with "/**".
> + * asymmetric_verify_v3_hashless - Use hashless signature verification on sigv3
> + * @key: The key to use for signature verification
> + * @pk: The associated public key
> + * @encoding: The encoding the key type uses
> + * @sig: The signature
> + * @siglen: The length of the xattr signature
> + * @algo: The hash algorithm
> + * @digest: The file digest
> + *
> + * Create an ima_file_id structure and use it for signature verification
> + * directly. This can be used for ML-DSA in pure mode for example.
Like the comments on 1/2, please add a comment here indicating that all callers
must verify the signature length (siglen) and the public key (pk) is not NULL,
before calling asymmetric_verify_v3_hashless(). Also indicate that the caller
must free the key.
> + */
> +static int asymmetric_verify_v3_hashless(struct key *key,
> + const struct public_key *pk,
> + const char *encoding,
> + const char *sig, int siglen,
> + u8 algo,
> + const u8 *digest)
> +{
> + struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
> + struct ima_file_id file_id = {
> + .hash_type = hdr->type,
> + .hash_algorithm = algo,
> + };
> + size_t digest_size = hash_digest_size[algo];
Defer initializing the digest_size and .m_size, below, until after checking the
hash algorithm is valid.
> + struct public_key_signature pks = {
> + .m = (u8 *)&file_id,
> + .m_size = sizeof(file_id) - (HASH_MAX_DIGESTSIZE - digest_size),
> + .s = hdr->sig,
> + .s_size = siglen - sizeof(*hdr),
> + .pkey_algo = pk->pkey_algo,
> + .hash_algo = "none",
> + .encoding = encoding,
> + };
> + int ret;
> +
> + if (hdr->type != IMA_VERITY_DIGSIG &&
> + hdr->type != EVM_IMA_XATTR_DIGSIG &&
> + hdr->type != EVM_XATTR_PORTABLE_DIGSIG)
> + return -EINVAL;
> +
> + if (pks.s_size != be16_to_cpu(hdr->sig_size))
> + return -EBADMSG;
> +
> + memcpy(file_id.hash, digest, digest_size);
First check the hash algorithm is valid, before using digest_size.
> +
> + ret = verify_signature(key, &pks);
> + pr_debug("%s() = %d\n", __func__, ret);
> + return ret;
> +}
> +
> int asymmetric_verify_v3(struct key *keyring, const char *sig, int siglen,
> const char *data, int datalen, u8 algo)
> {
> struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
> struct ima_max_digest_data hash;
> + const struct public_key *pk;
> + struct key *key;
> int rc;
>
> - rc = calc_file_id_hash(hdr->type, algo, data, &hash);
> - if (rc)
> - return -EINVAL;
> + if (siglen <= sizeof(*hdr))
> + return -EBADMSG;
> +
> + key = request_asymmetric_key(keyring, be32_to_cpu(hdr->keyid));
> + if (IS_ERR(key))
> + return PTR_ERR(key);
>
> - return asymmetric_verify(keyring, sig, siglen, hash.digest,
> - hash.hdr.length);
> + pk = asymmetric_key_public_key(key);
Please add a test to check that 'pk' isn't null.
> + if (!strncmp(pk->pkey_algo, "mldsa", 5)) {
> + rc = asymmetric_verify_v3_hashless(key, pk, "raw",
> + sig, siglen, algo, data);
> + } else {
> + rc = calc_file_id_hash(hdr->type, algo, data, &hash);
> + if (rc) {
> + rc = -EINVAL;
> + goto err_exit;
> + }
> +
> + rc = asymmetric_verify_common(key, pk, sig, siglen, hash.digest,
> + hash.hdr.length);
> + }
> +
> +err_exit:
Normally a label named 'err*' would be preceded by a return. Here, the label
"err_exit" is always called, not only when there is an error. Please rename the
label to something more appropriate - out, cleanup, etc.
> + key_put(key);
> +
> + return rc;
> }
thanks,
Mimi
^ permalink raw reply
* Re: [PATCH v2 1/2] integrity: Refactor asymmetric_verify for reusability
From: Mimi Zohar @ 2026-04-15 2:00 UTC (permalink / raw)
To: Stefan Berger, linux-integrity, linux-security-module
Cc: linux-kernel, roberto.sassu, ebiggers
In-Reply-To: <20260408174154.139606-2-stefanb@linux.ibm.com>
On Wed, 2026-04-08 at 13:41 -0400, Stefan Berger wrote:
> Refactor asymmetric_verify for reusability. Have it call
> asymmetric_verify_common with the signature verification key and the
> public_key structure as parameters. sigv3 support for ML-DSA will need to
> check the public key type first to decide how to do the signature
> verification and therefore will have these parameters available for
> calling asymmetric_verify_common.
>
> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Thanks, Stefan.
> ---
> security/integrity/digsig_asymmetric.c | 42 +++++++++++++++++---------
> 1 file changed, 28 insertions(+), 14 deletions(-)
>
> diff --git a/security/integrity/digsig_asymmetric.c b/security/integrity/digsig_asymmetric.c
> index 6e68ec3becbd..e29ed73f15cd 100644
> --- a/security/integrity/digsig_asymmetric.c
> +++ b/security/integrity/digsig_asymmetric.c
> @@ -79,18 +79,15 @@ static struct key *request_asymmetric_key(struct key *keyring, uint32_t keyid)
> return key;
> }
>
> -int asymmetric_verify(struct key *keyring, const char *sig,
> - int siglen, const char *data, int datalen)
> +static int asymmetric_verify_common(const struct key *key,
> + const struct public_key *pk,
> + const char *sig, int siglen,
> + const char *data, int datalen)
> {
> - struct public_key_signature pks;
> struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
> - const struct public_key *pk;
> - struct key *key;
> + struct public_key_signature pks;
> int ret;
>
> - if (siglen <= sizeof(*hdr))
> - return -EBADMSG;
> -
> siglen -= sizeof(*hdr);
Normally kernel-doc is unnecessary for static functions. Here, however, since
only the caller verifies the signature length, there should be a kernel-doc
function definition. It should indicate that all callers must verify the
signature length (siglen) and that the public key (pk) is not NULL, before
calling asymmetric_verify_common().
>
> if (siglen != be16_to_cpu(hdr->sig_size))
> @@ -99,15 +96,10 @@ int asymmetric_verify(struct key *keyring, const char *sig,
> if (hdr->hash_algo >= HASH_ALGO__LAST)
> return -ENOPKG;
>
> - key = request_asymmetric_key(keyring, be32_to_cpu(hdr->keyid));
> - if (IS_ERR(key))
> - return PTR_ERR(key);
> -
> memset(&pks, 0, sizeof(pks));
>
> pks.hash_algo = hash_algo_name[hdr->hash_algo];
>
> - pk = asymmetric_key_public_key(key);
> pks.pkey_algo = pk->pkey_algo;
> if (!strcmp(pk->pkey_algo, "rsa")) {
> pks.encoding = "pkcs1";
> @@ -127,11 +119,33 @@ int asymmetric_verify(struct key *keyring, const char *sig,
> pks.s_size = siglen;
> ret = verify_signature(key, &pks);
> out:
> - key_put(key);
The kernel-doc function definition should also indicate that the caller must
free the key.
> pr_debug("%s() = %d\n", __func__, ret);
> return ret;
> }
>
> +int asymmetric_verify(struct key *keyring, const char *sig,
> + int siglen, const char *data, int datalen)
> +{
> + struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
> + const struct public_key *pk;
> + struct key *key;
> + int ret;
> +
> + if (siglen <= sizeof(*hdr))
> + return -EBADMSG;
> +
> + key = request_asymmetric_key(keyring, be32_to_cpu(hdr->keyid));
> + if (IS_ERR(key))
> + return PTR_ERR(key);
> + pk = asymmetric_key_public_key(key);
Please add a test here making sure pk is not null.
thanks,
Mimi
> +
> + ret = asymmetric_verify_common(key, pk, sig, siglen, data, datalen);
> +
> + key_put(key);
> +
> + return ret;
> +}
> +
> /*
> * calc_file_id_hash - calculate the hash of the ima_file_id struct data
> * @type: xattr type [enum evm_ima_xattr_type]
^ permalink raw reply
* Re: [PATCH v3] KEYS: trusted: Debugging as a feature
From: Jarkko Sakkinen @ 2026-04-15 0:05 UTC (permalink / raw)
To: Nayna Jain
Cc: linux-integrity, keyrings, Srish Srinivasan, James Bottomley,
Mimi Zohar, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, Ahmad Fatoum, Pengutronix Kernel Team,
linux-kernel, linux-security-module
In-Reply-To: <129b137c-be9b-4b01-824f-beec7111377c@linux.ibm.com>
On Sun, Apr 12, 2026 at 02:47:20PM -0400, Nayna Jain wrote:
>
> On 4/9/26 12:07 PM, Jarkko Sakinen wrote:
> > From: Jarkko Sakkinen <jarkko@kernel.org>
> >
> > TPM_DEBUG, and other similar flags, are a non-standard way to specify a
> > feature in Linux kernel. Introduce CONFIG_TRUSTED_KEYS_DEBUG for trusted
> > keys, and use it to replace these ad-hoc feature flags.
> >
> > Given that trusted keys debug dumps can contain sensitive data, harden the
> > feature as follows:
> >
> > 1. In the Kconfig description postulate that pr_debug() statements must be
> > used.
> > 2. Use pr_debug() statements in TPM 1.x driver to print the protocol dump.
> > 3. Require trusted.debug=1 on the kernel command line (default: 0) to
> > activate dumps at runtime, even when CONFIG_TRUSTED_KEYS_DEBUG=y.
> >
> > Traces, when actually needed, can be easily enabled by providing
> > trusted.dyndbg='+p' and trusted.debug=1 in the kernel command-line.
>
> Thanks Jarkko. Additional changes looks good to me. I just realized that the
> kernel command-line parameters document may need to be updated to include
> these parameters.
Good point. I will bake that to my PR version of patch. It's low risk as
per corrateral damage. Thanks for pointing this out.
>
> Apart from that, feel free to add my
>
> Reviewed-by: Nayna Jain <nayna@linux.ibm.com>
Thank you! These defines have been a huge itch for me for a while :-)
>
> Thanks & Regards,
>
> - Nayna
>
>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v3] KEYS: trusted: Debugging as a feature
From: Jarkko Sakkinen @ 2026-04-15 0:03 UTC (permalink / raw)
To: Srish Srinivasan
Cc: linux-integrity, keyrings, Nayna Jain, James Bottomley,
Mimi Zohar, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, Ahmad Fatoum, Pengutronix Kernel Team,
linux-kernel, linux-security-module
In-Reply-To: <05c9a2c3-8077-4a1c-87f8-4e240ee1e5c4@linux.ibm.com>
On Fri, Apr 10, 2026 at 11:03:58PM +0530, Srish Srinivasan wrote:
>
> On 4/9/26 9:37 PM, Jarkko Sakinen wrote:
> > From: Jarkko Sakkinen <jarkko@kernel.org>
> >
> > TPM_DEBUG, and other similar flags, are a non-standard way to specify a
> > feature in Linux kernel. Introduce CONFIG_TRUSTED_KEYS_DEBUG for trusted
> > keys, and use it to replace these ad-hoc feature flags.
> >
> > Given that trusted keys debug dumps can contain sensitive data, harden the
> > feature as follows:
> >
> > 1. In the Kconfig description postulate that pr_debug() statements must be
> > used.
> > 2. Use pr_debug() statements in TPM 1.x driver to print the protocol dump.
> > 3. Require trusted.debug=1 on the kernel command line (default: 0) to
> > activate dumps at runtime, even when CONFIG_TRUSTED_KEYS_DEBUG=y.
> >
> > Traces, when actually needed, can be easily enabled by providing
> > trusted.dyndbg='+p' and trusted.debug=1 in the kernel command-line.
> >
> > Cc: Srish Srinivasan <ssrish@linux.ibm.com>
> > Reported-by: Nayna Jain <nayna@linux.ibm.com>
> > Closes: https://lore.kernel.org/all/7f8b8478-5cd8-4d97-bfd0-341fd5cf10f9@linux.ibm.com/
> > Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
>
>
> Tested on PKWM and emulated TPM backends.
>
> Tested-by: Srish Srinivasan <ssrish@linux.ibm.com>
Thank you!
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v2 0/4] Firmware LSM hook
From: Casey Schaufler @ 2026-04-14 22:42 UTC (permalink / raw)
To: Paul Moore
Cc: Jason Gunthorpe, Leon Romanovsky, Roberto Sassu, KP Singh,
Matt Bobrowski, Alexei Starovoitov, Daniel Borkmann,
John Fastabend, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Shuah Khan, Saeed Mahameed, Itay Avraham,
Dave Jiang, Jonathan Cameron, bpf, linux-kernel, linux-kselftest,
linux-rdma, Chiara Meiohas, Maher Sanalla, linux-security-module,
Casey Schaufler
In-Reply-To: <CAHC9VhRoaECt03Rs-ZyoGhW2_qZkA_1weTYYjiXc41Yf5U8A_g@mail.gmail.com>
On 4/14/2026 1:44 PM, Paul Moore wrote:
> On Tue, Apr 14, 2026 at 4:10 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 4/14/2026 12:09 PM, Paul Moore wrote:
>>> On Tue, Apr 14, 2026 at 1:05 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> ..
>
>>> For those of you who are interested in a more detailed explanation,
>>> here ya go ...
>>>
>>> NetLabel passes security attributes between itself and various LSMs
>>> through the netlbl_lsm_secattr struct. The netlbl_lsm_secattr struct
>>> is an abstraction not only for the underlying labeling protocols, e.g.
>>> CIPSO and CALIPSO, but also for the LSMs. Multiple LSMs call into
>>> NetLabel for the same inbound packet using netlbl_skbuff_getattr() and
>>> then translate the attributes into their own label representation.
>>>
>>> Outbound traffic is a bit more complicated as it involves changing the
>>> state of either a sock, via netlbl_sock_setattr(), or a packet, via
>>> netlbl_skbuff_setattr(), but in both cases we are once again dealing
>>> with netlbl_lsm_secattr struct, not a LSM specific label. Since the
>>> underlying labeling protocol is configured within the NetLabel
>>> subsystem and outside the individual LSMs, there is no worry about
>>> different LSMs requesting different protocol configurations (that is a
>>> separate system/network management issue). The only concern is that
>>> the on-the-wire representation is the same for each LSM that is using
>>> NetLabel based labeling. While some additional work would be
>>> required, it shouldn't be that hard to add NetLabel/protocol code to
>>> ensure the protocol specific labels are the same, and reject/drop the
>>> packet if not.
>> Indeed, we've discussed this, and I had at one point implemented it.
>> The problem is that for any meaningful access control policies you will
>> never get the two LSMs to agree on a unified network representation.
> That is also not correct. In the early days when SELinux was first
> being used to displace the old CMW/MLS UNIXes NetLabel/CIPSO was used
> to interoperate between the systems and it did so quite well despite
> the SELinux TE/MLS policy being quite different than the CMW MLS
> policies. Yes, there were aspects of the SELinux policy that made
> this easier - it had a MLS component after all - but they were still
> *very* different policies.
CMW MLS and SELinux MLS can be mapped. They have the same components.
Comparing a full SELinux context and a Smack label is another beast.
>> SELinux transmits the MLS component of the security context. Smack passes
>> the text of its context.
> Arguably the NetLabel/CIPSO interoperability challenge between SELinux
> and Smack is due more to differences in how Smack encodes its security
> labels into MLS attributes than from any inherent interop limitation.
Yes. That is correct. The big issue I see is that SELinux does not represent
the entire context in the CIPSO header. Thus, you're up against many SELinux
contexts having the same wire representation, where Smack will have a unique
on wire for each context. You'll have many-to-one mapping issues.
> In fact, I thought the "cipso2" Smack interface was intended to
> resolve this by allowing admins to control how a Smack/CIPSO
> translation so that Smack could interop with MLS systems, is that not
> the case?
Indeed. A CMW MLS policy is way simpler than an SELinux policy.
>
>> Unless the Smack label is completely in step with
>> the MLS component of the SELinux context there is no hope of a common
>> network representation. If a *very talented* sysadmin could create such a
>> policy, you would have to wonder why, because Smack would be duplicating
>> the SELinux MLS policy.
> Interoperability wouldn't be a problem if everyone the "right" systems :D
Where would the fun in that be? ;)
>
>>> Use of the NetLabel translation cache, e.g. netlbl_cache_add(), would
>>> require some additional work to convert over to a lsm_prop instead of
>>> a u32/secid, but if you look at the caching code that should be
>>> trivial. It might be as simple as adding a lsm_prop to the
>>> netlbl_lsm_secattr::attr struct since the cache stores a full secattr
>>> and not just a u32/secid.
>> Indeed. But with no viable users it seems like a lower priority task.
> You need to be very careful about those "viable users" claims ...
Today there are no users. There are other problems (e.g. mount options)
that have yet to be addressed.
>> And to be clear, I have no problem with netlabel as written. Multiple tag
>> support isn't simple (we did it for Trusted IRIX) and the limited space
>> available for IP options make it tricky.
> That's an entirely different problem from the LSM and protocol
> abstractions, but yeah.
>
^ permalink raw reply
* Re: [PATCH v2 0/4] Firmware LSM hook
From: Paul Moore @ 2026-04-14 20:44 UTC (permalink / raw)
To: Casey Schaufler
Cc: Jason Gunthorpe, Leon Romanovsky, Roberto Sassu, KP Singh,
Matt Bobrowski, Alexei Starovoitov, Daniel Borkmann,
John Fastabend, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Shuah Khan, Saeed Mahameed, Itay Avraham,
Dave Jiang, Jonathan Cameron, bpf, linux-kernel, linux-kselftest,
linux-rdma, Chiara Meiohas, Maher Sanalla, linux-security-module
In-Reply-To: <53a532e8-5981-49b4-896e-0bf5021ff78b@schaufler-ca.com>
On Tue, Apr 14, 2026 at 4:10 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 4/14/2026 12:09 PM, Paul Moore wrote:
> > On Tue, Apr 14, 2026 at 1:05 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
...
> > For those of you who are interested in a more detailed explanation,
> > here ya go ...
> >
> > NetLabel passes security attributes between itself and various LSMs
> > through the netlbl_lsm_secattr struct. The netlbl_lsm_secattr struct
> > is an abstraction not only for the underlying labeling protocols, e.g.
> > CIPSO and CALIPSO, but also for the LSMs. Multiple LSMs call into
> > NetLabel for the same inbound packet using netlbl_skbuff_getattr() and
> > then translate the attributes into their own label representation.
> >
> > Outbound traffic is a bit more complicated as it involves changing the
> > state of either a sock, via netlbl_sock_setattr(), or a packet, via
> > netlbl_skbuff_setattr(), but in both cases we are once again dealing
> > with netlbl_lsm_secattr struct, not a LSM specific label. Since the
> > underlying labeling protocol is configured within the NetLabel
> > subsystem and outside the individual LSMs, there is no worry about
> > different LSMs requesting different protocol configurations (that is a
> > separate system/network management issue). The only concern is that
> > the on-the-wire representation is the same for each LSM that is using
> > NetLabel based labeling. While some additional work would be
> > required, it shouldn't be that hard to add NetLabel/protocol code to
> > ensure the protocol specific labels are the same, and reject/drop the
> > packet if not.
>
> Indeed, we've discussed this, and I had at one point implemented it.
> The problem is that for any meaningful access control policies you will
> never get the two LSMs to agree on a unified network representation.
That is also not correct. In the early days when SELinux was first
being used to displace the old CMW/MLS UNIXes NetLabel/CIPSO was used
to interoperate between the systems and it did so quite well despite
the SELinux TE/MLS policy being quite different than the CMW MLS
policies. Yes, there were aspects of the SELinux policy that made
this easier - it had a MLS component after all - but they were still
*very* different policies.
> SELinux transmits the MLS component of the security context. Smack passes
> the text of its context.
Arguably the NetLabel/CIPSO interoperability challenge between SELinux
and Smack is due more to differences in how Smack encodes its security
labels into MLS attributes than from any inherent interop limitation.
In fact, I thought the "cipso2" Smack interface was intended to
resolve this by allowing admins to control how a Smack/CIPSO
translation so that Smack could interop with MLS systems, is that not
the case?
> Unless the Smack label is completely in step with
> the MLS component of the SELinux context there is no hope of a common
> network representation. If a *very talented* sysadmin could create such a
> policy, you would have to wonder why, because Smack would be duplicating
> the SELinux MLS policy.
Interoperability wouldn't be a problem if everyone the "right" systems :D
> > Use of the NetLabel translation cache, e.g. netlbl_cache_add(), would
> > require some additional work to convert over to a lsm_prop instead of
> > a u32/secid, but if you look at the caching code that should be
> > trivial. It might be as simple as adding a lsm_prop to the
> > netlbl_lsm_secattr::attr struct since the cache stores a full secattr
> > and not just a u32/secid.
>
> Indeed. But with no viable users it seems like a lower priority task.
You need to be very careful about those "viable users" claims ...
> And to be clear, I have no problem with netlabel as written. Multiple tag
> support isn't simple (we did it for Trusted IRIX) and the limited space
> available for IP options make it tricky.
That's an entirely different problem from the LSM and protocol
abstractions, but yeah.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v2 0/4] Firmware LSM hook
From: Paul Moore @ 2026-04-14 20:27 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Leon Romanovsky, Roberto Sassu, KP Singh, Matt Bobrowski,
Alexei Starovoitov, Daniel Borkmann, John Fastabend,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, Stanislav Fomichev, Hao Luo, Jiri Olsa, Shuah Khan,
Saeed Mahameed, Itay Avraham, Dave Jiang, Jonathan Cameron, bpf,
linux-kernel, linux-kselftest, linux-rdma, Chiara Meiohas,
Maher Sanalla, linux-security-module
In-Reply-To: <20260413231920.GS3694781@ziepe.ca>
On Mon, Apr 13, 2026 at 7:19 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> On Mon, Apr 13, 2026 at 06:36:06PM -0400, Paul Moore wrote:
> > On Mon, Apr 13, 2026 at 12:42 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> > > On Sun, Apr 12, 2026 at 09:38:35PM -0400, Paul Moore wrote:
> > > > > We are not limited to LSM solution, the goal is to intercept commands
> > > > > which are submitted to the FW and "security" bucket sounded right to us.
> > > >
> > > > Yes, it does sound "security relevant", but without a well defined
> > > > interface/format it is going to be difficult to write a generic LSM to
> > > > have any level of granularity beyond a basic "load firmware"
> > > > permission.
> > >
> > > I think to step back a bit, what this is trying to achieve is very
> > > similar to the iptables fwmark/secmark scheme.
> >
> > Points for thinking outside the box a bit, but from what I've seen
> > thus far, it differs from secmark in a few important areas. The
> > secmark concept relies on the admin to configure the network stack to
> > apply secmark labels to network traffic as it flows through the
> > system, the LSM then applies security policy to these packets based on
> > their label. The firmware LSM hooks, at least as I currently
> > understand them, rely on the LSM hook callback to parse the firmware
> > op/request and apply a security policy to the request.
>
> That was what was proposed because the idea was to combine the
> parse/clasification/decision steps into one eBPF program, but I think
> it can be split up too.
>
> > We've already talked about the first issue, parsing the request, and
> > my suggestion was to make the LSM hook call from within the firmware
> > (the firmware must have some way to call into the kernel/driver code,
> > no?)
>
> No, that's not workable on so many levels. It is sort of anaologous to
> asking the NIC to call the LSM to apply the secmark while sending the
> packet.
From the LSM's perspective it really doesn't matter who calls the LSM
hook as long as the caller can be trusted to handle the access control
verdict properly.
> The proper flow has the kernel evaluate the packet/command *before* it
> delivers it to HW, not after.
From what I can see that's an artificial constraint since we've
already chosen to trust the device. After all, if we don't trust the
device, why are we talking to it?
> > so that only the firmware would need to parse the request. If we
> > wanted to adopt a secmark-esque approach, one could develop a second
> > parsing mechanism that would be responsible for assigning a LSM label
> > to the request, and then pass the firmware request to the LSM, but I
> > do worry a bit about the added complexity associated with keeping the
> > parser sync'd with the driver/fw.
>
> In practice it would be like iptables, the parser would be entirely
> programmed by userspace and there is nothing to keep in sync.
You've mentioned a few times now that the firmware/request will vary
across not only devices, but firmware revisions too, this implies
there will need to be some effort to keep whatever parser you develop
(BPF, userspace config, etc.) in sync with the parser built into the
firmware. Or am I misunderstanding something?
> > However, even if we solve the parsing problem, I worry we have
> > another, closely related issue, of having to categorize all of the
> > past, present, and future firmware requests into a set of LSM specific
> > actions.
>
> Why? secmark doesn't have this issue? The classifer would return the
> same kind of information as secmark, some user provided label that is
> delivered to the LSM policy side.
I think there is a misunderstanding in either how secmark works or how
the LSMs use secmark labels when enforcing their security policy.
The secmark label is set on a packet to represent the network
properties of a packet. While the rules governing how a packet's
secmark is set and the semantic meaning of that secmark label is going
to be LSM and solution specific, secmark labels represent the
properties of a packet and not the operation, e.g.
send/receive/forward/etc., being requested at a given access control
point. The access control point itself represents the requested
operation. This is possible because the number of networking
operations on a given packet is well defined and fairly limited; at a
high level the packet is either being sent from the node, received by
the node, or is passing through the node.
As I understand the firmware controls being proposed here, encoded
within the firmware request blob is the operation being requested.
While we've discussed possible solutions on how to parse the request
blob to determine the operation, we haven't really discussed how to
represent the requested operation to the LSMs. I'm assuming there
isn't a well defined set of operations, and like the request format
itself, the set of valid operations will vary from device and firmware
revision. I hope you can understand both how this differs from
secmark and that it is a challenge that really hasn't been addressed
in the proposals we've discussed.
At a very high level the access control decision for firmware/device
requests depends on whether the LSM wants to allow process A to do B
to device C. The identity/credentials associated with process A are
easy to understand, we have plenty of examples both inside and outside
of the LSM on how to do that. The device identity/attributes
associated with device C can be a bit trickier, but once again we have
plenty of examples to draw from, and we can even fall back to a
generic "kernel" id/attribute if the LSM chooses not to distinguish
entities below the userspace/kernel boundary. I think the hardest
issue with the firmware request hooks is going to be determining what
operation is being requested, the "B", portion of access request
tuple. If we can create a well defined set of operations and leave it
to the parser to characterize the operation we've potentially got a
solution, but if the operation is truly going to be arbitrary then we
have a real problem. How do you craft a meaningful access control
policy when you don't understand what is being requested?
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v2 0/4] Firmware LSM hook
From: Casey Schaufler @ 2026-04-14 20:09 UTC (permalink / raw)
To: Paul Moore
Cc: Jason Gunthorpe, Leon Romanovsky, Roberto Sassu, KP Singh,
Matt Bobrowski, Alexei Starovoitov, Daniel Borkmann,
John Fastabend, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Shuah Khan, Saeed Mahameed, Itay Avraham,
Dave Jiang, Jonathan Cameron, bpf, linux-kernel, linux-kselftest,
linux-rdma, Chiara Meiohas, Maher Sanalla, linux-security-module,
Casey Schaufler
In-Reply-To: <CAHC9VhTm9MG-NzdwxtqJA6LZeTEsmUjyy8da2=8KOVxgDtEqWQ@mail.gmail.com>
On 4/14/2026 12:09 PM, Paul Moore wrote:
> On Tue, Apr 14, 2026 at 1:05 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> Netlabel has a similar issue to secmarks with its use of secids, and
>> currently supports only a single CIPSO tag in the IP header, making
>> multiple concurrent LSM support impossible.
> That's not correct.
OK, you're right. However ...
>
> We've talked about this multiple times Casey. The short version is
> that while NetLabel doesn't support multiple simultaneous LSMs at the
> moment (mostly due to an issue with outbound traffic), this is not due
> to some inherent limitation, it is due to the fact that it wasn't
> needed when NetLabel was created, and no one has done the (relatively
> minor) work to add support since then.
>
> For those of you who are interested in a more detailed explanation,
> here ya go ...
>
> NetLabel passes security attributes between itself and various LSMs
> through the netlbl_lsm_secattr struct. The netlbl_lsm_secattr struct
> is an abstraction not only for the underlying labeling protocols, e.g.
> CIPSO and CALIPSO, but also for the LSMs. Multiple LSMs call into
> NetLabel for the same inbound packet using netlbl_skbuff_getattr() and
> then translate the attributes into their own label representation.
>
> Outbound traffic is a bit more complicated as it involves changing the
> state of either a sock, via netlbl_sock_setattr(), or a packet, via
> netlbl_skbuff_setattr(), but in both cases we are once again dealing
> with netlbl_lsm_secattr struct, not a LSM specific label. Since the
> underlying labeling protocol is configured within the NetLabel
> subsystem and outside the individual LSMs, there is no worry about
> different LSMs requesting different protocol configurations (that is a
> separate system/network management issue). The only concern is that
> the on-the-wire representation is the same for each LSM that is using
> NetLabel based labeling. While some additional work would be
> required, it shouldn't be that hard to add NetLabel/protocol code to
> ensure the protocol specific labels are the same, and reject/drop the
> packet if not.
Indeed, we've discussed this, and I had at one point implemented it.
The problem is that for any meaningful access control policies you will
never get the two LSMs to agree on a unified network representation.
SELinux transmits the MLS component of the security context. Smack passes
the text of its context. Unless the Smack label is completely in step with
the MLS component of the SELinux context there is no hope of a common
network representation. If a *very talented* sysadmin could create such a
policy, you would have to wonder why, because Smack would be duplicating
the SELinux MLS policy.
So there's really no value in pursuing that approach.
> Use of the NetLabel translation cache, e.g. netlbl_cache_add(), would
> require some additional work to convert over to a lsm_prop instead of
> a u32/secid, but if you look at the caching code that should be
> trivial. It might be as simple as adding a lsm_prop to the
> netlbl_lsm_secattr::attr struct since the cache stores a full secattr
> and not just a u32/secid.
Indeed. But with no viable users it seems like a lower priority task.
And to be clear, I have no problem with netlabel as written. Multiple tag
support isn't simple (we did it for Trusted IRIX) and the limited space
available for IP options make it tricky.
^ permalink raw reply
* Re: [RFC PATCH v4 00/19] Support socket access-control
From: Mikhail Ivanov @ 2026-04-14 19:45 UTC (permalink / raw)
To: Mickaël Salaün
Cc: gnoack, willemdebruijn.kernel, matthieu, linux-security-module,
netdev, netfilter-devel, yusongping, artem.kuzin,
konstantin.meskhidze
In-Reply-To: <20260414.thaeki1iigeM@digikod.net>
On 4/14/2026 5:27 PM, Mickaël Salaün wrote:
> On Mon, Apr 13, 2026 at 08:11:48PM +0300, Mikhail Ivanov wrote:
>> On 4/8/2026 1:26 PM, Mickaël Salaün wrote:
>>> Hi Mikhail,
>>
>> Hi!
>>
>>>
>>> On Tue, Nov 18, 2025 at 09:46:20PM +0800, Mikhail Ivanov wrote:
>>>> Hello! This is v4 RFC patch dedicated to socket protocols restriction.
>>>>
>>>> It is based on the landlock's mic-next branch on top of Linux 6.16-rc2
>>>> kernel version.
>>>>
>>>> Objective
>>>> =========
>>>> Extend Landlock with a mechanism to restrict any set of protocols in
>>>> a sandboxed process.
>>>>
>>>> Closes: https://github.com/landlock-lsm/linux/issues/6
>>>>
>>>> Motivation
>>>> ==========
>>>> Landlock implements the `LANDLOCK_RULE_NET_PORT` rule type, which provides
>>>> fine-grained control of actions for a specific protocol. Any action or
>>>> protocol that is not supported by this rule can not be controlled. As a
>>>> result, protocols for which fine-grained control is not supported can be
>>>> used in a sandboxed system and lead to vulnerabilities or unexpected
>>>> behavior.
>>>>
>>>> Controlling the protocols used will allow to use only those that are
>>>> necessary for the system and/or which have fine-grained Landlock control
>>>> through others types of rules (e.g. TCP bind/connect control with
>>>> `LANDLOCK_RULE_NET_PORT`, UNIX bind control with
>>>> `LANDLOCK_RULE_PATH_BENEATH`).
>>>>
>>>> Consider following examples:
>>>> * Server may want to use only TCP sockets for which there is fine-grained
>>>> control of bind(2) and connect(2) actions [1].
>>>> * System that does not need a network or that may want to disable network
>>>> for security reasons (e.g. [2]) can achieve this by restricting the use
>>>> of all possible protocols.
>>>>
>>>> [1] https://lore.kernel.org/all/ZJvy2SViorgc+cZI@google.com/
>>>> [2] https://cr.yp.to/unix/disablenetwork.html
>>>>
>>>> Implementation
>>>> ==============
>>>> This patchset adds control over the protocols used by implementing a
>>>> restriction of socket creation. This is possible thanks to the new type
>>>> of rule - `LANDLOCK_RULE_SOCKET`, that allows to restrict actions on
>>>> sockets, and a new access right - `LANDLOCK_ACCESS_SOCKET_CREATE`, that
>>>> corresponds to user space sockets creation. The key in this rule
>>>> corresponds to communication protocol signature from socket(2) syscall.
>>>
>>> FYI, I sent a new patch series that adds a handled_perm field to
>>> rulesets:
>>> https://lore.kernel.org/all/20260312100444.2609563-6-mic@digikod.net/
>>> See also the rationale:
>>> https://lore.kernel.org/all/20260312100444.2609563-12-mic@digikod.net/
>>>
>>> I think that would work well with the socket creation permission. WDYT?
>>
>> Agreed. AFAICS restrictions of protocols used for communication (eg.TCP)
>> will complement restriction of network namespace which sandboxed process
>> is pinned by LANDLOCK_PERM_NAMESPACE_ENTER permission.
>
> I mean that socket creation restriction should use the same handled_perm
> interface e.g. add a LANDLOCK_PERM_SOCKET_CREATE right with related
> LANDLOCK_RULE_SOCKET rule type.
Oh, I see your point.
>
> With the first RFC for handled_perm, the related rules (e.g. struct
> landlock_socket_attr) don't have an allowed_access field but an
> allowed_perm one instead. The related permission would then be
> LANDLOCK_PERM_SOCKET_CREATE. WDYT?
Of course, thats reasonable. We haven't come up with reasonable ideas of
access rights for LANDLOCK_RULE_SOCKET except socket creation, so
current patchset will fit in handled_perm design very well.
>
>>
>>>
>>> Do you think you'll be able to continue this work or would you like me
>>> or Günther to complete the remaining last bits (while of course keeping
>>> you as the main author)?
>>
>> Sorry for the delay. I will finish and send patch series ASAP.
>
> This new version should then be on top of the Landlock namespace and
> capability patchset to reuse the handled_perm interface. I plan to send
> a new version by the end of the month, but this should not change the
> handled_perm interface.
OK. I will send RFC v5 based on current design for the review anyway.
>
>>
>>>
>>>
>>>>
>>>> The right to create a socket is checked in the LSM hook which is called
>>>> in the __sock_create method. The following user space operations are
>>>> subject to this check: socket(2), socketpair(2), io_uring(7).
>>>>
>>>> `LANDLOCK_ACCESS_SOCKET_CREATE` does not restrict socket creation
>>>> performed by accept(2), because created socket is used for messaging
>>>> between already existing endpoints.
>>>>
>>>> Design discussion
>>>> ===================
>>>> 1. Should `SCTP_SOCKOPT_PEELOFF` and socketpair(2) be restricted?
>>>>
>>>> SCTP socket can be connected to a multiple endpoints (one-to-many
>>>> relation). Calling setsockopt(2) on such socket with option
>>>> `SCTP_SOCKOPT_PEELOFF` detaches one of existing connections to a separate
>>>> UDP socket. This detach is currently restrictable.
>>>>
>>>> Same applies for the socketpair(2) syscall. It was noted that denying
>>>> usage of socketpair(2) in sandboxed environment may be not meaninful [1].
>>>>
>>>> Currently both operations use general socket interface to create sockets.
>>>> Therefore it's not possible to distinguish between socket(2) and those
>>>> operations inside security_socket_create LSM hook which is currently
>>>> used for protocols restriction. Providing such separation may require
>>>> changes in socket layer (eg. in __sock_create) interface which may not be
>>>> acceptable.
>>>>
>>>> [1] https://lore.kernel.org/all/ZurZ7nuRRl0Zf2iM@google.com/
>>>>
>>>> Code coverage
>>>> =============
>>>> Code coverage(gcov) report with the launch of all the landlock selftests:
>>>> * security/landlock:
>>>> lines......: 94.0% (1200 of 1276 lines)
>>>> functions..: 95.0% (134 of 141 functions)
>>>>
>>>> * security/landlock/socket.c:
>>>> lines......: 100.0% (56 of 56 lines)
>>>> functions..: 100.0% (5 of 5 functions)
>>>>
>>>> Currently landlock-test-tools fails on mini.kernel_socket test due to lack
>>>> of SMC protocol support.
>>>>
>>>> General changes v3->v4
>>>> ======================
>>>> * Implementation
>>>> * Adds protocol field to landlock_socket_attr.
>>>> * Adds protocol masks support via wildcards values in
>>>> landlock_socket_attr.
>>>> * Changes LSM hook used from socket_post_create to socket_create.
>>>> * Changes protocol ranges acceptable by socket rules.
>>>> * Adds audit support.
>>>> * Changes ABI version to 8.
>>>> * Tests
>>>> * Adds 5 new tests:
>>>> * mini.rule_with_wildcard, protocol_wildcard.access,
>>>> mini.ruleset_with_wildcards_overlap:
>>>> verify rulesets containing rules with wildcard values.
>>>> * tcp_protocol.alias_restriction: verify that Landlock doesn't
>>>> perform protocol mappings.
>>>> * audit.socket_create: tests audit denial logging.
>>>> * Squashes tests corresponding to Landlock rule adding to a single commit.
>>>> * Documentation
>>>> * Refactors Documentation/userspace-api/landlock.rst.
>>>> * Commits
>>>> * Rebases on mic-next.
>>>> * Refactors commits.
>>>>
>>>> Previous versions
>>>> =================
>>>> v3: https://lore.kernel.org/all/20240904104824.1844082-1-ivanov.mikhail1@huawei-partners.com/
>>>> v2: https://lore.kernel.org/all/20240524093015.2402952-1-ivanov.mikhail1@huawei-partners.com/
>>>> v1: https://lore.kernel.org/all/20240408093927.1759381-1-ivanov.mikhail1@huawei-partners.com/
>>>>
>>>> Mikhail Ivanov (19):
>>>> landlock: Support socket access-control
>>>> selftests/landlock: Test creating a ruleset with unknown access
>>>> selftests/landlock: Test adding a socket rule
>>>> selftests/landlock: Testing adding rule with wildcard value
>>>> selftests/landlock: Test acceptable ranges of socket rule key
>>>> landlock: Add hook on socket creation
>>>> selftests/landlock: Test basic socket restriction
>>>> selftests/landlock: Test network stack error code consistency
>>>> selftests/landlock: Test overlapped rulesets with rules of protocol
>>>> ranges
>>>> selftests/landlock: Test that kernel space sockets are not restricted
>>>> selftests/landlock: Test protocol mappings
>>>> selftests/landlock: Test socketpair(2) restriction
>>>> selftests/landlock: Test SCTP peeloff restriction
>>>> selftests/landlock: Test that accept(2) is not restricted
>>>> lsm: Support logging socket common data
>>>> landlock: Log socket creation denials
>>>> selftests/landlock: Test socket creation denial log for audit
>>>> samples/landlock: Support socket protocol restrictions
>>>> landlock: Document socket rule type support
>>>>
>>>> Documentation/userspace-api/landlock.rst | 48 +-
>>>> include/linux/lsm_audit.h | 8 +
>>>> include/uapi/linux/landlock.h | 60 +-
>>>> samples/landlock/sandboxer.c | 118 +-
>>>> security/landlock/Makefile | 2 +-
>>>> security/landlock/access.h | 3 +
>>>> security/landlock/audit.c | 12 +
>>>> security/landlock/audit.h | 1 +
>>>> security/landlock/limits.h | 4 +
>>>> security/landlock/ruleset.c | 37 +-
>>>> security/landlock/ruleset.h | 46 +-
>>>> security/landlock/setup.c | 2 +
>>>> security/landlock/socket.c | 198 +++
>>>> security/landlock/socket.h | 20 +
>>>> security/landlock/syscalls.c | 61 +-
>>>> security/lsm_audit.c | 4 +
>>>> tools/testing/selftests/landlock/base_test.c | 2 +-
>>>> tools/testing/selftests/landlock/common.h | 14 +
>>>> tools/testing/selftests/landlock/config | 47 +
>>>> tools/testing/selftests/landlock/net_test.c | 11 -
>>>> .../selftests/landlock/protocols_define.h | 169 +++
>>>> .../testing/selftests/landlock/socket_test.c | 1169 +++++++++++++++++
>>>> 22 files changed, 1990 insertions(+), 46 deletions(-)
>>>> create mode 100644 security/landlock/socket.c
>>>> create mode 100644 security/landlock/socket.h
>>>> create mode 100644 tools/testing/selftests/landlock/protocols_define.h
>>>> create mode 100644 tools/testing/selftests/landlock/socket_test.c
>>>>
>>>>
>>>> base-commit: 6dde339a3df80a57ac3d780d8cfc14d9262e2acd
>>>> --
>>>> 2.34.1
>>>>
>>>>
>>
^ permalink raw reply
* Re: [PATCH v2 0/4] Firmware LSM hook
From: Paul Moore @ 2026-04-14 19:09 UTC (permalink / raw)
To: Casey Schaufler
Cc: Jason Gunthorpe, Leon Romanovsky, Roberto Sassu, KP Singh,
Matt Bobrowski, Alexei Starovoitov, Daniel Borkmann,
John Fastabend, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Shuah Khan, Saeed Mahameed, Itay Avraham,
Dave Jiang, Jonathan Cameron, bpf, linux-kernel, linux-kselftest,
linux-rdma, Chiara Meiohas, Maher Sanalla, linux-security-module
In-Reply-To: <4cf6b20b-f53b-4b5e-ba03-c7ac01bec0c2@schaufler-ca.com>
On Tue, Apr 14, 2026 at 1:05 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> Netlabel has a similar issue to secmarks with its use of secids, and
> currently supports only a single CIPSO tag in the IP header, making
> multiple concurrent LSM support impossible.
That's not correct.
We've talked about this multiple times Casey. The short version is
that while NetLabel doesn't support multiple simultaneous LSMs at the
moment (mostly due to an issue with outbound traffic), this is not due
to some inherent limitation, it is due to the fact that it wasn't
needed when NetLabel was created, and no one has done the (relatively
minor) work to add support since then.
For those of you who are interested in a more detailed explanation,
here ya go ...
NetLabel passes security attributes between itself and various LSMs
through the netlbl_lsm_secattr struct. The netlbl_lsm_secattr struct
is an abstraction not only for the underlying labeling protocols, e.g.
CIPSO and CALIPSO, but also for the LSMs. Multiple LSMs call into
NetLabel for the same inbound packet using netlbl_skbuff_getattr() and
then translate the attributes into their own label representation.
Outbound traffic is a bit more complicated as it involves changing the
state of either a sock, via netlbl_sock_setattr(), or a packet, via
netlbl_skbuff_setattr(), but in both cases we are once again dealing
with netlbl_lsm_secattr struct, not a LSM specific label. Since the
underlying labeling protocol is configured within the NetLabel
subsystem and outside the individual LSMs, there is no worry about
different LSMs requesting different protocol configurations (that is a
separate system/network management issue). The only concern is that
the on-the-wire representation is the same for each LSM that is using
NetLabel based labeling. While some additional work would be
required, it shouldn't be that hard to add NetLabel/protocol code to
ensure the protocol specific labels are the same, and reject/drop the
packet if not.
Use of the NetLabel translation cache, e.g. netlbl_cache_add(), would
require some additional work to convert over to a lsm_prop instead of
a u32/secid, but if you look at the caching code that should be
trivial. It might be as simple as adding a lsm_prop to the
netlbl_lsm_secattr::attr struct since the cache stores a full secattr
and not just a u32/secid.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v2 0/4] Firmware LSM hook
From: Casey Schaufler @ 2026-04-14 17:05 UTC (permalink / raw)
To: Jason Gunthorpe, Paul Moore
Cc: Leon Romanovsky, Roberto Sassu, KP Singh, Matt Bobrowski,
Alexei Starovoitov, Daniel Borkmann, John Fastabend,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, Stanislav Fomichev, Hao Luo, Jiri Olsa, Shuah Khan,
Saeed Mahameed, Itay Avraham, Dave Jiang, Jonathan Cameron, bpf,
linux-kernel, linux-kselftest, linux-rdma, Chiara Meiohas,
Maher Sanalla, linux-security-module, Casey Schaufler
In-Reply-To: <20260413231920.GS3694781@ziepe.ca>
On 4/13/2026 4:19 PM, Jason Gunthorpe wrote:
> On Mon, Apr 13, 2026 at 06:36:06PM -0400, Paul Moore wrote:
>> On Mon, Apr 13, 2026 at 12:42 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
>>> On Sun, Apr 12, 2026 at 09:38:35PM -0400, Paul Moore wrote:
>>>>> We are not limited to LSM solution, the goal is to intercept commands
>>>>> which are submitted to the FW and "security" bucket sounded right to us.
>>>> Yes, it does sound "security relevant", but without a well defined
>>>> interface/format it is going to be difficult to write a generic LSM to
>>>> have any level of granularity beyond a basic "load firmware"
>>>> permission.
>>> I think to step back a bit, what this is trying to achieve is very
>>> similar to the iptables fwmark/secmark scheme.
>> Points for thinking outside the box a bit, but from what I've seen
>> thus far, it differs from secmark in a few important areas. The
>> secmark concept relies on the admin to configure the network stack to
>> apply secmark labels to network traffic as it flows through the
>> system, the LSM then applies security policy to these packets based on
>> their label. The firmware LSM hooks, at least as I currently
>> understand them, rely on the LSM hook callback to parse the firmware
>> op/request and apply a security policy to the request.
> That was what was proposed because the idea was to combine the
> parse/clasification/decision steps into one eBPF program, but I think
> it can be split up too.
>
>> We've already talked about the first issue, parsing the request, and
>> my suggestion was to make the LSM hook call from within the firmware
>> (the firmware must have some way to call into the kernel/driver code,
>> no?)
> No, that's not workable on so many levels. It is sort of anaologous to
> asking the NIC to call the LSM to apply the secmark while sending the
> packet.
>
> The proper flow has the kernel evaluate the packet/command *before* it
> delivers it to HW, not after.
>
>> so that only the firmware would need to parse the request. If we
>> wanted to adopt a secmark-esque approach, one could develop a second
>> parsing mechanism that would be responsible for assigning a LSM label
>> to the request, and then pass the firmware request to the LSM, but I
>> do worry a bit about the added complexity associated with keeping the
>> parser sync'd with the driver/fw.
> In practice it would be like iptables, the parser would be entirely
> programmed by userspace and there is nothing to keep in sync.
>
>> However, even if we solve the parsing problem, I worry we have
>> another, closely related issue, of having to categorize all of the
>> past, present, and future firmware requests into a set of LSM specific
>> actions.
> Why? secmark doesn't have this issue? The classifer would return the
> same kind of information as secmark, some user provided label that is
> delivered to the LSM policy side.
>
> When I talk about a classifier I mean a user programmable classifer
> like iptables. secmark obviously doesn't raise future looking
> questions (like what if there is httpv3?) nor should this.
Secmark has already failed. As I mentioned before, you can't fit the
label information from more than one LSM in a u32. There's going to have
to be some performance degrading hash-magic invoked to make that happen,
and when I've looked into what it would take I was very unhappy.
>> The past and present requests are just a matter of code,
>> that isn't too worrying, but what do we do about unknown future
>> requests? Beyond simply encoding the request into a operation
>> token/enum/int, what additional information beyond the action type
>> would a LSM need to know to apply a security policy? Would it be
>> reasonable to blindly allow or reject unknown requests? If so, what
>> would break?
> I am proposing something like SECMARK.
>
> Eg from Google:
>
> iptables -t mangle -A INPUT -p tcp --dport 80 -j SECMARK --selctx system_u:object_r:httpd_packet_t:s0
>
> Which is 'match a packet to see that byte offset XX is 0080 and if so
> tag it with the thing this string describes'
>
> So I'm imagining the same kind of flexability. User provides the
> matching and whatever those strings are. The classifer step is fully
> flexible. No worry about future stuff.
>
> I'm guessing when Casey talks about struct lsm_prop it is related to
> the system_u string?
Yeah, that would be it. Lets say your system supports SELinux and AppArmor.
You'll need to be able to specify an SELinux context, an AppArmor context,
or both. Iptables can't do that because of the limitations of a secmark.
>>> ... Once classified we want this to work with more than SELinux
>>> only, we have a particular interest in the eBPF LSM.
>> One of the design requirements for the LSM framework is that it
>> provides an abstraction layer between the kernel and the underlying
>> security mechanisms implemented by the various LSMs. Some operations
>> will always fall outside the scope of individual LSMs due to their
>> nature, but as a general rule we try to ensure that LSM hooks are
>> useful across multiple LSMs.
> I don't know much about SECMARK but Google is telling me it doesn't
> work with anything but SELinux LSM? We'd just like to avoid this
> pitful and I guess that is why Casey brings up lsm_prop?
Google is wrong. (Imagine that!) Smack uses secmarks. It's one of the
reasons you can't use SELinux and Smack at the same time. There is code
in iptables that implies it only works for SELinux, but it isn't true.
That's why you want an lsm_prop instead of a secid. The limitation of a
secmark is imposed by the IP stack implementation. It would be very
frustrating if you introduced yet another scheme with that limitation.
>>> Following the fwmark example, if there was some programmable in-kernel
>>> function to convert the cmd into a SELinux label would we be able to
>>> enable SELinux following the SECMARK design?
>> As Casey already mentioned, any sort of classifier would need to be
>> able to support multiple LSMs. The only example that comes to mind at
>> the moment is the NetLabel mechanism which translates between
>> on-the-wire CIPSO and CALIPSO labels and multiple LSMs (Smack and
>> SELinux currently).
> Ok, I think they can look into that, it is a good lead
Netlabel has a similar issue to secmarks with its use of secids, and
currently supports only a single CIPSO tag in the IP header, making
multiple concurrent LSM support impossible. If you're defining a new
mechanism you can avoid this limitation.
>>> Would there be an objection if that in-kernel function was using a
>>> system-wide eBPF uploaded with some fwctl uAPI?
>> We'd obviously need to see patches, but there is precedent in
>> separating labeling from enforcement. We've discussed SecMark and
>> NetLabel in the networking space, but technically, the VFS/filesystem
>> xattr implementations could also be considered as a labeling mechanism
>> outside of the LSM.
> Makes sense
>
>>> Finally, would there be an objection to enabling the same function in
>>> eBPF by feeding it the entire command and have it classify and make a
>>> security decision in a single eBPF program?
>> Keeping in mind that from an LSM perspective we need to support
>> multiple implementations, both in terms of language mechanics (eBPF,
>> Rust, C) and security philosophies (Smack, SELinux, AppArmor, etc.),
>> so it would be very unlikely that we would want a specific shortcut or
>> mechanism that would only work for one language or philosophy.
> Okay, it is good to understand the sensitivities
>
>>> Is there some other way to enable eBPF?
>> If one develops a workable LSM hook then I see no reason why one
>> couldn't write a BPF LSM to use that hook; that's what we do today.
> I was thinking that too
>
>> However, it seems like direct reuse of secmark isn't what is needed,
>> or even wanted, you were just using that as an example of separating
>> labeling from enforcement, yes?
> Yes, and looking for a coding example to guide implementing it, and to
> recast this discussion to something more concrete. It is very helpful
> to think of this a lot like deep packet inspection and
> classification.
>
> That the packets are delivered to FW and execute commands is not
> actually that important. IP packets are also delivered to remote CPUs
> and execute commands there too <shrug>
>
> At the end of the day the task is the same - deep packet inspection,
> classification. labeling, policy decision, enforcement.
>
> Thanks,
> Jason
>
^ permalink raw reply
* RE: [syzbot] Monthly lsm report (Apr 2026)
From: Roberto Sassu @ 2026-04-14 15:42 UTC (permalink / raw)
To: Paul Moore, Mimi Zohar
Cc: linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
syzkaller-bugs@googlegroups.com, syzbot
In-Reply-To: <CAHC9VhTO4z1oPnNK748oTU6H7FcnxL2yzbuqkEKAfsrDV2Rcig@mail.gmail.com>
> From: Paul Moore <paul@paul-moore.com>
> Sent: Tuesday, April 14, 2026 3:59 PM
> On Tue, Apr 14, 2026 at 2:48 AM syzbot
> <syzbot+liste5004e02dae137bbd339@syzkaller.appspotmail.com> wrote:
> >
> > Hello lsm maintainers/developers,
> >
> > This is a 31-day syzbot report for the lsm subsystem.
> > All related reports/information can be found at:
> > https://syzkaller.appspot.com/upstream/s/lsm
> >
> > During the period, 0 new issues were detected and 0 were fixed.
> > In total, 3 issues are still open and 45 have already been fixed.
> >
> > Some of the still happening issues:
> >
> > Ref Crashes Repro Title
> > <1> 95 Yes INFO: task hung in process_measurement (3)
> >
> https://syzkaller.appspot.com/bug?extid=cb9e66807bcb882cd0c5
> > <2> 68 Yes possible deadlock in keyring_clear (3)
> >
> https://syzkaller.appspot.com/bug?extid=f55b043dacf43776b50c
> > <3> 31 Yes INFO: task hung in ima_file_free (4)
> >
> > https://syzkaller.appspot.com/bug?extid=8036326eebe7d0140944
>
> Mimi, Roberto,
>
> If I recall correctly, we've discussed the process measurement issue before,
> and I thought it was being resolved. What is the current status on a fix?
>
> I don't recall discussing the ima_file_free() issue, but it looks like the syzbot
> reports go back to 2024; is there a fix under development for that?
I looked at some of the reports. My impression (can be wrong) is that the
syzbot report involves us also when a filesystem gets stuck.
For example, if you see:
https://syzkaller.appspot.com/text?tag=CrashReport&x=160ddb02580000
PID 6887 cannot progress because iint->mutex is likely held by PID 6895.
The last function I see in PID 6895 is io_schedule() which suggests me
that there is an I/O wait that could not be satisfied. PID 6888 cannot progress
as well because is waiting for jfs_get_block(), but PID 6895 is past that
(possibly holding the needed lock).
Sure, it is possible that there is a lock inversion that I missed, but I didn't
find it yet.
Roberto
> Thanks.
>
> > ---
> > This report is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> > syzbot engineers can be reached at syzkaller@googlegroups.com.
> >
> > To disable reminders for individual bugs, reply with the following
> command:
> > #syz set <Ref> no-reminders
> >
> > To change bug's subsystems, reply with:
> > #syz set <Ref> subsystems: new-subsystem
> >
> > You may send multiple commands in a single email message.
>
> --
> paul-moore.com
^ permalink raw reply
* Re: [RFC PATCH v4 00/19] Support socket access-control
From: Mickaël Salaün @ 2026-04-14 14:27 UTC (permalink / raw)
To: Mikhail Ivanov
Cc: gnoack, willemdebruijn.kernel, matthieu, linux-security-module,
netdev, netfilter-devel, yusongping, artem.kuzin,
konstantin.meskhidze
In-Reply-To: <ca9b74f3-ce72-1d7f-c922-be1b276b69a8@huawei-partners.com>
On Mon, Apr 13, 2026 at 08:11:48PM +0300, Mikhail Ivanov wrote:
> On 4/8/2026 1:26 PM, Mickaël Salaün wrote:
> > Hi Mikhail,
>
> Hi!
>
> >
> > On Tue, Nov 18, 2025 at 09:46:20PM +0800, Mikhail Ivanov wrote:
> > > Hello! This is v4 RFC patch dedicated to socket protocols restriction.
> > >
> > > It is based on the landlock's mic-next branch on top of Linux 6.16-rc2
> > > kernel version.
> > >
> > > Objective
> > > =========
> > > Extend Landlock with a mechanism to restrict any set of protocols in
> > > a sandboxed process.
> > >
> > > Closes: https://github.com/landlock-lsm/linux/issues/6
> > >
> > > Motivation
> > > ==========
> > > Landlock implements the `LANDLOCK_RULE_NET_PORT` rule type, which provides
> > > fine-grained control of actions for a specific protocol. Any action or
> > > protocol that is not supported by this rule can not be controlled. As a
> > > result, protocols for which fine-grained control is not supported can be
> > > used in a sandboxed system and lead to vulnerabilities or unexpected
> > > behavior.
> > >
> > > Controlling the protocols used will allow to use only those that are
> > > necessary for the system and/or which have fine-grained Landlock control
> > > through others types of rules (e.g. TCP bind/connect control with
> > > `LANDLOCK_RULE_NET_PORT`, UNIX bind control with
> > > `LANDLOCK_RULE_PATH_BENEATH`).
> > >
> > > Consider following examples:
> > > * Server may want to use only TCP sockets for which there is fine-grained
> > > control of bind(2) and connect(2) actions [1].
> > > * System that does not need a network or that may want to disable network
> > > for security reasons (e.g. [2]) can achieve this by restricting the use
> > > of all possible protocols.
> > >
> > > [1] https://lore.kernel.org/all/ZJvy2SViorgc+cZI@google.com/
> > > [2] https://cr.yp.to/unix/disablenetwork.html
> > >
> > > Implementation
> > > ==============
> > > This patchset adds control over the protocols used by implementing a
> > > restriction of socket creation. This is possible thanks to the new type
> > > of rule - `LANDLOCK_RULE_SOCKET`, that allows to restrict actions on
> > > sockets, and a new access right - `LANDLOCK_ACCESS_SOCKET_CREATE`, that
> > > corresponds to user space sockets creation. The key in this rule
> > > corresponds to communication protocol signature from socket(2) syscall.
> >
> > FYI, I sent a new patch series that adds a handled_perm field to
> > rulesets:
> > https://lore.kernel.org/all/20260312100444.2609563-6-mic@digikod.net/
> > See also the rationale:
> > https://lore.kernel.org/all/20260312100444.2609563-12-mic@digikod.net/
> >
> > I think that would work well with the socket creation permission. WDYT?
>
> Agreed. AFAICS restrictions of protocols used for communication (eg.TCP)
> will complement restriction of network namespace which sandboxed process
> is pinned by LANDLOCK_PERM_NAMESPACE_ENTER permission.
I mean that socket creation restriction should use the same handled_perm
interface e.g. add a LANDLOCK_PERM_SOCKET_CREATE right with related
LANDLOCK_RULE_SOCKET rule type.
With the first RFC for handled_perm, the related rules (e.g. struct
landlock_socket_attr) don't have an allowed_access field but an
allowed_perm one instead. The related permission would then be
LANDLOCK_PERM_SOCKET_CREATE. WDYT?
>
> >
> > Do you think you'll be able to continue this work or would you like me
> > or Günther to complete the remaining last bits (while of course keeping
> > you as the main author)?
>
> Sorry for the delay. I will finish and send patch series ASAP.
This new version should then be on top of the Landlock namespace and
capability patchset to reuse the handled_perm interface. I plan to send
a new version by the end of the month, but this should not change the
handled_perm interface.
>
> >
> >
> > >
> > > The right to create a socket is checked in the LSM hook which is called
> > > in the __sock_create method. The following user space operations are
> > > subject to this check: socket(2), socketpair(2), io_uring(7).
> > >
> > > `LANDLOCK_ACCESS_SOCKET_CREATE` does not restrict socket creation
> > > performed by accept(2), because created socket is used for messaging
> > > between already existing endpoints.
> > >
> > > Design discussion
> > > ===================
> > > 1. Should `SCTP_SOCKOPT_PEELOFF` and socketpair(2) be restricted?
> > >
> > > SCTP socket can be connected to a multiple endpoints (one-to-many
> > > relation). Calling setsockopt(2) on such socket with option
> > > `SCTP_SOCKOPT_PEELOFF` detaches one of existing connections to a separate
> > > UDP socket. This detach is currently restrictable.
> > >
> > > Same applies for the socketpair(2) syscall. It was noted that denying
> > > usage of socketpair(2) in sandboxed environment may be not meaninful [1].
> > >
> > > Currently both operations use general socket interface to create sockets.
> > > Therefore it's not possible to distinguish between socket(2) and those
> > > operations inside security_socket_create LSM hook which is currently
> > > used for protocols restriction. Providing such separation may require
> > > changes in socket layer (eg. in __sock_create) interface which may not be
> > > acceptable.
> > >
> > > [1] https://lore.kernel.org/all/ZurZ7nuRRl0Zf2iM@google.com/
> > >
> > > Code coverage
> > > =============
> > > Code coverage(gcov) report with the launch of all the landlock selftests:
> > > * security/landlock:
> > > lines......: 94.0% (1200 of 1276 lines)
> > > functions..: 95.0% (134 of 141 functions)
> > >
> > > * security/landlock/socket.c:
> > > lines......: 100.0% (56 of 56 lines)
> > > functions..: 100.0% (5 of 5 functions)
> > >
> > > Currently landlock-test-tools fails on mini.kernel_socket test due to lack
> > > of SMC protocol support.
> > >
> > > General changes v3->v4
> > > ======================
> > > * Implementation
> > > * Adds protocol field to landlock_socket_attr.
> > > * Adds protocol masks support via wildcards values in
> > > landlock_socket_attr.
> > > * Changes LSM hook used from socket_post_create to socket_create.
> > > * Changes protocol ranges acceptable by socket rules.
> > > * Adds audit support.
> > > * Changes ABI version to 8.
> > > * Tests
> > > * Adds 5 new tests:
> > > * mini.rule_with_wildcard, protocol_wildcard.access,
> > > mini.ruleset_with_wildcards_overlap:
> > > verify rulesets containing rules with wildcard values.
> > > * tcp_protocol.alias_restriction: verify that Landlock doesn't
> > > perform protocol mappings.
> > > * audit.socket_create: tests audit denial logging.
> > > * Squashes tests corresponding to Landlock rule adding to a single commit.
> > > * Documentation
> > > * Refactors Documentation/userspace-api/landlock.rst.
> > > * Commits
> > > * Rebases on mic-next.
> > > * Refactors commits.
> > >
> > > Previous versions
> > > =================
> > > v3: https://lore.kernel.org/all/20240904104824.1844082-1-ivanov.mikhail1@huawei-partners.com/
> > > v2: https://lore.kernel.org/all/20240524093015.2402952-1-ivanov.mikhail1@huawei-partners.com/
> > > v1: https://lore.kernel.org/all/20240408093927.1759381-1-ivanov.mikhail1@huawei-partners.com/
> > >
> > > Mikhail Ivanov (19):
> > > landlock: Support socket access-control
> > > selftests/landlock: Test creating a ruleset with unknown access
> > > selftests/landlock: Test adding a socket rule
> > > selftests/landlock: Testing adding rule with wildcard value
> > > selftests/landlock: Test acceptable ranges of socket rule key
> > > landlock: Add hook on socket creation
> > > selftests/landlock: Test basic socket restriction
> > > selftests/landlock: Test network stack error code consistency
> > > selftests/landlock: Test overlapped rulesets with rules of protocol
> > > ranges
> > > selftests/landlock: Test that kernel space sockets are not restricted
> > > selftests/landlock: Test protocol mappings
> > > selftests/landlock: Test socketpair(2) restriction
> > > selftests/landlock: Test SCTP peeloff restriction
> > > selftests/landlock: Test that accept(2) is not restricted
> > > lsm: Support logging socket common data
> > > landlock: Log socket creation denials
> > > selftests/landlock: Test socket creation denial log for audit
> > > samples/landlock: Support socket protocol restrictions
> > > landlock: Document socket rule type support
> > >
> > > Documentation/userspace-api/landlock.rst | 48 +-
> > > include/linux/lsm_audit.h | 8 +
> > > include/uapi/linux/landlock.h | 60 +-
> > > samples/landlock/sandboxer.c | 118 +-
> > > security/landlock/Makefile | 2 +-
> > > security/landlock/access.h | 3 +
> > > security/landlock/audit.c | 12 +
> > > security/landlock/audit.h | 1 +
> > > security/landlock/limits.h | 4 +
> > > security/landlock/ruleset.c | 37 +-
> > > security/landlock/ruleset.h | 46 +-
> > > security/landlock/setup.c | 2 +
> > > security/landlock/socket.c | 198 +++
> > > security/landlock/socket.h | 20 +
> > > security/landlock/syscalls.c | 61 +-
> > > security/lsm_audit.c | 4 +
> > > tools/testing/selftests/landlock/base_test.c | 2 +-
> > > tools/testing/selftests/landlock/common.h | 14 +
> > > tools/testing/selftests/landlock/config | 47 +
> > > tools/testing/selftests/landlock/net_test.c | 11 -
> > > .../selftests/landlock/protocols_define.h | 169 +++
> > > .../testing/selftests/landlock/socket_test.c | 1169 +++++++++++++++++
> > > 22 files changed, 1990 insertions(+), 46 deletions(-)
> > > create mode 100644 security/landlock/socket.c
> > > create mode 100644 security/landlock/socket.h
> > > create mode 100644 tools/testing/selftests/landlock/protocols_define.h
> > > create mode 100644 tools/testing/selftests/landlock/socket_test.c
> > >
> > >
> > > base-commit: 6dde339a3df80a57ac3d780d8cfc14d9262e2acd
> > > --
> > > 2.34.1
> > >
> > >
>
^ permalink raw reply
* Re: LSM: Whiteout chardev creation sidesteps mknod hook
From: Miklos Szeredi @ 2026-04-14 14:07 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Günther Noack, Christian Brauner, Serge Hallyn,
Amir Goldstein, Paul Moore, linux-security-module
In-Reply-To: <20260414.gailoogieGh0@digikod.net>
On Tue, 14 Apr 2026 at 15:42, Mickaël Salaün <mic@digikod.net> wrote:
> BTW, I don't understand why only the renameat2(2) syscall can
> (indirectly) create this file type; why not also unlink(2) or rmdir(2)?
The reason is that the same effect is possible with first creating the
whiteout in the work directory with mknod, then renaming it over the
target. Since the work directory is needed anyway, this spares
filesystems from having to implement yet another overlayfs specific
operation.
Thanks,
Miklos
^ permalink raw reply
* Re: [syzbot] Monthly lsm report (Apr 2026)
From: Paul Moore @ 2026-04-14 14:02 UTC (permalink / raw)
To: Jarkko Sakkinen, David Howells
Cc: linux-kernel, linux-security-module, syzkaller-bugs, syzbot
In-Reply-To: <69dde155.050a0220.3030df.004d.GAE@google.com>
On Tue, Apr 14, 2026 at 2:48 AM syzbot
<syzbot+liste5004e02dae137bbd339@syzkaller.appspotmail.com> wrote:
>
> Hello lsm maintainers/developers,
>
> This is a 31-day syzbot report for the lsm subsystem.
> All related reports/information can be found at:
> https://syzkaller.appspot.com/upstream/s/lsm
>
> During the period, 0 new issues were detected and 0 were fixed.
> In total, 3 issues are still open and 45 have already been fixed.
>
> Some of the still happening issues:
>
> Ref Crashes Repro Title
> <1> 95 Yes INFO: task hung in process_measurement (3)
> https://syzkaller.appspot.com/bug?extid=cb9e66807bcb882cd0c5
> <2> 68 Yes possible deadlock in keyring_clear (3)
> https://syzkaller.appspot.com/bug?extid=f55b043dacf43776b50c
Jarkko, David,
Do we have a fix for the keyring_clear() issue, or is it not a real problem?
> <3> 31 Yes INFO: task hung in ima_file_free (4)
> https://syzkaller.appspot.com/bug?extid=8036326eebe7d0140944
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> To disable reminders for individual bugs, reply with the following command:
> #syz set <Ref> no-reminders
>
> To change bug's subsystems, reply with:
> #syz set <Ref> subsystems: new-subsystem
>
> You may send multiple commands in a single email message.
--
paul-moore.com
^ permalink raw reply
* Re: [syzbot] Monthly lsm report (Apr 2026)
From: Paul Moore @ 2026-04-14 13:59 UTC (permalink / raw)
To: Mimi Zohar, Roberto Sassu
Cc: linux-kernel, linux-security-module, syzkaller-bugs, syzbot
In-Reply-To: <69dde155.050a0220.3030df.004d.GAE@google.com>
On Tue, Apr 14, 2026 at 2:48 AM syzbot
<syzbot+liste5004e02dae137bbd339@syzkaller.appspotmail.com> wrote:
>
> Hello lsm maintainers/developers,
>
> This is a 31-day syzbot report for the lsm subsystem.
> All related reports/information can be found at:
> https://syzkaller.appspot.com/upstream/s/lsm
>
> During the period, 0 new issues were detected and 0 were fixed.
> In total, 3 issues are still open and 45 have already been fixed.
>
> Some of the still happening issues:
>
> Ref Crashes Repro Title
> <1> 95 Yes INFO: task hung in process_measurement (3)
> https://syzkaller.appspot.com/bug?extid=cb9e66807bcb882cd0c5
> <2> 68 Yes possible deadlock in keyring_clear (3)
> https://syzkaller.appspot.com/bug?extid=f55b043dacf43776b50c
> <3> 31 Yes INFO: task hung in ima_file_free (4)
> https://syzkaller.appspot.com/bug?extid=8036326eebe7d0140944
Mimi, Roberto,
If I recall correctly, we've discussed the process measurement issue
before, and I thought it was being resolved. What is the current
status on a fix?
I don't recall discussing the ima_file_free() issue, but it looks like
the syzbot reports go back to 2024; is there a fix under development
for that?
Thanks.
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> To disable reminders for individual bugs, reply with the following command:
> #syz set <Ref> no-reminders
>
> To change bug's subsystems, reply with:
> #syz set <Ref> subsystems: new-subsystem
>
> You may send multiple commands in a single email message.
--
paul-moore.com
^ permalink raw reply
* Re: LSM: Whiteout chardev creation sidesteps mknod hook
From: Mickaël Salaün @ 2026-04-14 13:42 UTC (permalink / raw)
To: Günther Noack
Cc: Miklos Szeredi, Christian Brauner, Serge Hallyn, Amir Goldstein,
Paul Moore, linux-security-module
In-Reply-To: <adzgKVIhRj5t3GqM@google.com>
On Mon, Apr 13, 2026 at 02:23:05PM +0200, Günther Noack wrote:
> On Mon, Apr 13, 2026 at 12:18:08PM +0200, Miklos Szeredi wrote:
> > On Sat, 11 Apr 2026 at 10:36, Günther Noack <gnoack@google.com> wrote:
> > > I also don't currently see how an attacker would abuse this, but I still see
> > > this as a violation of Landlock's security model if we can create a policy that
> > > denies the creation of character device directory entries, and then we still
> > > have a way to make them appear there where we previously had a different file.
> >
> > Look: a whiteout is a whiteout, NOT a character device. Don't let the
> > fact that it's represented by "c 0 0" fool you, this is a completely
> > different beast. See commit a3c751a50fe6 ("vfs: allow unprivileged
> > whiteout creation").
> >
> > Does this beast need special handling by LSMs? I have no idea, but
> > treating them the same as char devs sounds like a bad idea.
>
> Thanks for the pointer to that commit. I was under the impression
> that creation of the whiteout objects required CAP_MKNOD, but it seems
> you have dropped that requirement in that commit.
>
> (FWIW, I was mislead by the rename(2) man page[1], which is apparently
> not up to date and where it explicitly says:
>
> RENAME_WHITEOUT requires the same privileges as creating a
> device node (i.e., the CAP_MKNOD capability).
>
> So with that assumption, it seemed natural that this should have
> extended equivalently into a Landlock policy.)
I agree with Miklos and also pointed out to this commit:
https://lore.kernel.org/all/20260408.beu1Eing5aFo@digikod.net/
>
> So if the "c 0 0" whiteout device is indeed a different kind of file,
> maybe we would need to treat it with a separate Landlock access right
> after all then. I'll ponder it.
What is sure is that we should not treat it like character devices,
which required special capabilities/permissions because they are a door
to a driver interface.
>
> FWIW, besides introducing a new LANDLOCK_ACCESS_FS_MAKE_WHITEOUT
> access right and adding more special cases to the Landlock API,
> another possible option might be to just forbid creating whiteout
> objects altogether, when under a Landlock policy.
This doesn't feel right. Mount operations restriction are there because
Landlock currently cannot properly control mount operations yet (see
https://github.com/landlock-lsm/linux/issues/14).
> As the man page
> also notes, "This operation makes sense only for overlay/union
> filesystem implementations",
The man pages contain at least one important error wrt this feature, so
we should only trust the kernel code. Anyway, anyone can create a
whiteout with mknod, so let's consider that there are other use cases.
> and since these likely can't use Landlock
> anyway due to mounting, I think there would be no use case left where
> anyone would want to perform such an operation within a Landlock
> domain -- I don't think this would break anyone. Mickaël, do you have
> an opinion on that idea?
The LANDLOCK_ACCESS_FS_MAKE_WHITEOUT right makes sense wrt other MAKE_*
rights (i.e. per file type). See may detailed reply here:
https://lore.kernel.org/r/20260414.Lae5ida1eeGh@digikod.net
BTW, I don't understand why only the renameat2(2) syscall can
(indirectly) create this file type; why not also unlink(2) or rmdir(2)?
>
> —Günther
>
> P.S. Initial patch set from Saturday is at [2], but this still uses
> the LANDLOCK_ACCESS_FS_MAKE_CHAR right.
>
> [1] https://man7.org/linux/man-pages/man2/rename.2.html
> [2] https://lore.kernel.org/all/20260411090944.3131168-2-gnoack@google.com/
>
^ permalink raw reply
* Re: [PATCH 0/3] landlock: Restrict renameat2 with RENAME_WHITEOUT
From: Mickaël Salaün @ 2026-04-14 13:40 UTC (permalink / raw)
To: Günther Noack
Cc: Christian Brauner, linux-security-module, Paul Moore,
Amir Goldstein, Miklos Szeredi, Serge Hallyn
In-Reply-To: <20260411090944.3131168-2-gnoack@google.com>
Thanks for bringing this up.
By default, creating whiteout files is not privileged e.g.,
mknod whiteout c 0 0 is allowed for unprivileged users. Landlock should
follow this semantic. So there are two issues:
1. LANDLOCK_ACCESS_FS_MAKE_CHAR should not apply for whiteouts.
2. Whiteouts creation should be controllable by Landlock (e.g. through
mknod and renameat2).
I see four options:
1. Consider whiteouts as regular files and make them handled by
LANDLOCK_ACCESS_FS_MAKE_REG. This would require an erratum and would
make sense for direct mknod calls, but it would be weird for
renameat2 calls than move a file and should only require
LANDLOCK_ACCESS_FS_REMOVE_FILE from the user point of view.
2. Add a new LANDLOCK_ACCESS_FS_MAKE_WHITEOUT right to handle whitout
creation (direct and indirect?) and keep LANDLOCK_ACCESS_FS_MAKE_CHAR
handle direct whiteout creation (and don't backport anything). It
looks inconsistent from an access control point of view.
3. Add a new LANDLOCK_ACCESS_FS_MAKE_WHITEOUT right and, when handled,
make LANDLOCK_ACCESS_FS_MAKE_CHAR not handle whiteout. This would be
a bit weird from a kernel point of view but it should work well for
users while still forbidding direct whiteout creation.
4. Add a new LANDLOCK_ACCESS_FS_MAKE_WHITEOUT right and make
LANDLOCK_ACCESS_FS_MAKE_CHAR never handle whiteout (and backport
MAKE_CHAR fix with an errata). This would be consistent but backport
a way to directly create whiteouts (e.g. with mknod).
I think option 3 is the more pragmatic. Landlock should properly log
the right blocker wrt handled access rights though.
On Sat, Apr 11, 2026 at 11:09:42AM +0200, Günther Noack wrote:
> Hello!
>
> As discussed in [1], the renameat2() syscall's RENAME_WHITEOUT flag allows
> the creation of chardev directory entries with major=minor=0 as "whiteout
> objects" in the location of the rename source file [2].
>
> This functionality is available even without having any OverlayFS mounted
> and can be invoked with the regular renameat2(2) syscall [3].
>
>
> Motivation
> ==========
>
> The RENAME_WHITEOUT flag side-steps Landlock's LANDLOCK_ACCESS_FS_MAKE_CHAR
> right, which is designed to restrict the creation of chardev device files.
>
> This patch set fixes that by adding a check in Landlock's path_rename hook.
>
>
> Tradeoffs considered in the implementation
> ==========================================
>
> Q: Should we guard it with a dedicated LANDLOCK_ACCESS_FS_MAKE_WHITEOUT
> right?
>
> Pros:
> * This would be the fully backwards compatible solution,
> and Linux always strives for full backward compatibility.
>
> Cons:
> * Complicates the Landlock API surface for a very minor use case.
>
> In Debian Code search, the only use of RENAME_WHITEOUT from userspace
> seems to be for fuse-overlayfs. It is used there for the same purpose
> as in the kernel OverlayFS and it likely does not run in a Landlock
> domain.
>
> The tradeoff does not seem worth it to me. The chances that we break
> anyone with this seem very low, and I'm inclined to treat it as a bugfix
> for the existing LANDLOCK_ACCESS_FS_MAKE_CHAR right.
>
>
> Q: Should we add a Landlock erratum for this?
>
> I punted on it for now, but we can do it if needed.
>
> Q: Should the access right check be merged into the longer
> current_check_refer_path() function?
>
> I am leaning towards keeping it as a special case earlier. This means
> that we traverse the source path twice, but as we have seen in Debian
> Code Search, there are apparently no legitimate callers of renameat2()
> with RENAME_WHITEOUT who are calling this from within a Landlock domain.
> (fuse-overlayfs is legitimate, but is not landlocked)
>
> It doesn't seem worth complicating our common rename code for a corner
> case that doesn't happen in practice.
>
>
> [1] https://lore.kernel.org/all/adUBCQXrt7kmgqJT@google.com/
> [2] https://docs.kernel.org/filesystems/overlayfs.html#whiteouts-and-opaque-directories
> [3] https://man7.org/linux/man-pages/man2/renameat2.2.html#DESCRIPTION
> [4] https://codesearch.debian.net/search?q=rename.*RENAME_WHITEOUT&literal=0
>
>
> Günther Noack (3):
> landlock: Require LANDLOCK_ACCESS_FS_MAKE_CHAR for RENAME_WHITEOUT
> selftests/landlock: Add test for RENAME_WHITEOUT denial
> selftests/landlock: Test OverlayFS renames w/o
> LANDLOCK_ACCESS_FS_MAKE_CHAR
>
> security/landlock/fs.c | 16 ++++++++
> tools/testing/selftests/landlock/fs_test.c | 45 ++++++++++++++++++++++
> 2 files changed, 61 insertions(+)
>
> --
> 2.54.0.rc0.605.g598a273b03-goog
>
>
^ permalink raw reply
* [syzbot] Monthly lsm report (Apr 2026)
From: syzbot @ 2026-04-14 6:40 UTC (permalink / raw)
To: linux-kernel, linux-security-module, syzkaller-bugs
Hello lsm maintainers/developers,
This is a 31-day syzbot report for the lsm subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/lsm
During the period, 0 new issues were detected and 0 were fixed.
In total, 3 issues are still open and 45 have already been fixed.
Some of the still happening issues:
Ref Crashes Repro Title
<1> 95 Yes INFO: task hung in process_measurement (3)
https://syzkaller.appspot.com/bug?extid=cb9e66807bcb882cd0c5
<2> 68 Yes possible deadlock in keyring_clear (3)
https://syzkaller.appspot.com/bug?extid=f55b043dacf43776b50c
<3> 31 Yes INFO: task hung in ima_file_free (4)
https://syzkaller.appspot.com/bug?extid=8036326eebe7d0140944
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
To disable reminders for individual bugs, reply with the following command:
#syz set <Ref> no-reminders
To change bug's subsystems, reply with:
#syz set <Ref> subsystems: new-subsystem
You may send multiple commands in a single email message.
^ permalink raw reply
* Re: [PATCH v2 0/4] Firmware LSM hook
From: Jason Gunthorpe @ 2026-04-13 23:19 UTC (permalink / raw)
To: Paul Moore
Cc: Leon Romanovsky, Roberto Sassu, KP Singh, Matt Bobrowski,
Alexei Starovoitov, Daniel Borkmann, John Fastabend,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, Stanislav Fomichev, Hao Luo, Jiri Olsa, Shuah Khan,
Saeed Mahameed, Itay Avraham, Dave Jiang, Jonathan Cameron, bpf,
linux-kernel, linux-kselftest, linux-rdma, Chiara Meiohas,
Maher Sanalla, linux-security-module
In-Reply-To: <CAHC9VhR1Uke9P==CELKavBcogHoNCtMZFfNWUbgm5HYUfomhtw@mail.gmail.com>
On Mon, Apr 13, 2026 at 06:36:06PM -0400, Paul Moore wrote:
> On Mon, Apr 13, 2026 at 12:42 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> > On Sun, Apr 12, 2026 at 09:38:35PM -0400, Paul Moore wrote:
> > > > We are not limited to LSM solution, the goal is to intercept commands
> > > > which are submitted to the FW and "security" bucket sounded right to us.
> > >
> > > Yes, it does sound "security relevant", but without a well defined
> > > interface/format it is going to be difficult to write a generic LSM to
> > > have any level of granularity beyond a basic "load firmware"
> > > permission.
> >
> > I think to step back a bit, what this is trying to achieve is very
> > similar to the iptables fwmark/secmark scheme.
>
> Points for thinking outside the box a bit, but from what I've seen
> thus far, it differs from secmark in a few important areas. The
> secmark concept relies on the admin to configure the network stack to
> apply secmark labels to network traffic as it flows through the
> system, the LSM then applies security policy to these packets based on
> their label. The firmware LSM hooks, at least as I currently
> understand them, rely on the LSM hook callback to parse the firmware
> op/request and apply a security policy to the request.
That was what was proposed because the idea was to combine the
parse/clasification/decision steps into one eBPF program, but I think
it can be split up too.
> We've already talked about the first issue, parsing the request, and
> my suggestion was to make the LSM hook call from within the firmware
> (the firmware must have some way to call into the kernel/driver code,
> no?)
No, that's not workable on so many levels. It is sort of anaologous to
asking the NIC to call the LSM to apply the secmark while sending the
packet.
The proper flow has the kernel evaluate the packet/command *before* it
delivers it to HW, not after.
> so that only the firmware would need to parse the request. If we
> wanted to adopt a secmark-esque approach, one could develop a second
> parsing mechanism that would be responsible for assigning a LSM label
> to the request, and then pass the firmware request to the LSM, but I
> do worry a bit about the added complexity associated with keeping the
> parser sync'd with the driver/fw.
In practice it would be like iptables, the parser would be entirely
programmed by userspace and there is nothing to keep in sync.
> However, even if we solve the parsing problem, I worry we have
> another, closely related issue, of having to categorize all of the
> past, present, and future firmware requests into a set of LSM specific
> actions.
Why? secmark doesn't have this issue? The classifer would return the
same kind of information as secmark, some user provided label that is
delivered to the LSM policy side.
When I talk about a classifier I mean a user programmable classifer
like iptables. secmark obviously doesn't raise future looking
questions (like what if there is httpv3?) nor should this.
> The past and present requests are just a matter of code,
> that isn't too worrying, but what do we do about unknown future
> requests? Beyond simply encoding the request into a operation
> token/enum/int, what additional information beyond the action type
> would a LSM need to know to apply a security policy? Would it be
> reasonable to blindly allow or reject unknown requests? If so, what
> would break?
I am proposing something like SECMARK.
Eg from Google:
iptables -t mangle -A INPUT -p tcp --dport 80 -j SECMARK --selctx system_u:object_r:httpd_packet_t:s0
Which is 'match a packet to see that byte offset XX is 0080 and if so
tag it with the thing this string describes'
So I'm imagining the same kind of flexability. User provides the
matching and whatever those strings are. The classifer step is fully
flexible. No worry about future stuff.
I'm guessing when Casey talks about struct lsm_prop it is related to
the system_u string?
> > ... Once classified we want this to work with more than SELinux
> > only, we have a particular interest in the eBPF LSM.
>
> One of the design requirements for the LSM framework is that it
> provides an abstraction layer between the kernel and the underlying
> security mechanisms implemented by the various LSMs. Some operations
> will always fall outside the scope of individual LSMs due to their
> nature, but as a general rule we try to ensure that LSM hooks are
> useful across multiple LSMs.
I don't know much about SECMARK but Google is telling me it doesn't
work with anything but SELinux LSM? We'd just like to avoid this
pitful and I guess that is why Casey brings up lsm_prop?
> > Following the fwmark example, if there was some programmable in-kernel
> > function to convert the cmd into a SELinux label would we be able to
> > enable SELinux following the SECMARK design?
>
> As Casey already mentioned, any sort of classifier would need to be
> able to support multiple LSMs. The only example that comes to mind at
> the moment is the NetLabel mechanism which translates between
> on-the-wire CIPSO and CALIPSO labels and multiple LSMs (Smack and
> SELinux currently).
Ok, I think they can look into that, it is a good lead
> > Would there be an objection if that in-kernel function was using a
> > system-wide eBPF uploaded with some fwctl uAPI?
>
> We'd obviously need to see patches, but there is precedent in
> separating labeling from enforcement. We've discussed SecMark and
> NetLabel in the networking space, but technically, the VFS/filesystem
> xattr implementations could also be considered as a labeling mechanism
> outside of the LSM.
Makes sense
> > Finally, would there be an objection to enabling the same function in
> > eBPF by feeding it the entire command and have it classify and make a
> > security decision in a single eBPF program?
>
> Keeping in mind that from an LSM perspective we need to support
> multiple implementations, both in terms of language mechanics (eBPF,
> Rust, C) and security philosophies (Smack, SELinux, AppArmor, etc.),
> so it would be very unlikely that we would want a specific shortcut or
> mechanism that would only work for one language or philosophy.
Okay, it is good to understand the sensitivities
> > Is there some other way to enable eBPF?
>
> If one develops a workable LSM hook then I see no reason why one
> couldn't write a BPF LSM to use that hook; that's what we do today.
I was thinking that too
> However, it seems like direct reuse of secmark isn't what is needed,
> or even wanted, you were just using that as an example of separating
> labeling from enforcement, yes?
Yes, and looking for a coding example to guide implementing it, and to
recast this discussion to something more concrete. It is very helpful
to think of this a lot like deep packet inspection and
classification.
That the packets are delivered to FW and execute commands is not
actually that important. IP packets are also delivered to remote CPUs
and execute commands there too <shrug>
At the end of the day the task is the same - deep packet inspection,
classification. labeling, policy decision, enforcement.
Thanks,
Jason
^ permalink raw reply
* [GIT PULL] IPE update for 7.1
From: Fan Wu @ 2026-04-13 23:11 UTC (permalink / raw)
To: torvalds; +Cc: Linux Kernel Mailing List, linux-security-module
Hi Linus,
Please merge this PR for the IPE (Integrity Policy Enforcement) update for 7.1.
This PR contains a single commit from Evan Ducas that fixes several
spelling and grammar mistakes in the IPE documentation. There are no
functional changes.
Thanks,
Fan
--
The following changes since commit 028ef9c96e96197026887c0f092424679298aae8:
Linux 7.0 (2026-04-12 13:48:06 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/wufan/ipe.git
tags/ipe-pr-20260413
for you to fetch changes up to d46515ec0b1d4ae07f8f437515c43cfb6eb61ffa:
docs: security: ipe: fix typos and grammar (2026-04-13 15:58:49 -0700)
----------------------------------------------------------------
ipe/stable-7.1 PR 20260413
----------------------------------------------------------------
Evan Ducas (1):
docs: security: ipe: fix typos and grammar
Documentation/security/ipe.rst | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
^ permalink raw reply
* Re: [GIT PULL] selinux/selinux-pr-20260410
From: pr-tracker-bot @ 2026-04-13 22:48 UTC (permalink / raw)
To: Paul Moore; +Cc: Linus Torvalds, selinux, linux-security-module, linux-kernel
In-Reply-To: <60af9bced9ea23be5deffcb469805ff5@paul-moore.com>
The pull request you sent on Fri, 10 Apr 2026 19:26:11 -0400:
> https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git tags/selinux-pr-20260410
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b206a6fb9a105be198cf2dc435ffa4ad7c75ddc2
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL] lsm/lsm-pr-20260410
From: pr-tracker-bot @ 2026-04-13 22:47 UTC (permalink / raw)
To: Paul Moore; +Cc: Linus Torvalds, linux-security-module, linux-kernel
In-Reply-To: <9a2a59bd8d9548fb5dab128f4859fa3d@paul-moore.com>
The pull request you sent on Fri, 10 Apr 2026 19:26:05 -0400:
> https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git tags/lsm-pr-20260410
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3ba310f2a3ca70f0497aab5c2e8aa85a12e19406
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox