* Re: [PATCH] ipe: remove headers that are included but not used
From: Fan Wu @ 2025-12-03 22:25 UTC (permalink / raw)
To: Yicong Hui
Cc: wufan, paul, jmorris, serge, linux-security-module, linux-kernel
In-Reply-To: <20251203193718.504344-1-yiconghui@gmail.com>
On Wed, Dec 3, 2025 at 11:37 AM Yicong Hui <yiconghui@gmail.com> wrote:
>
> Remove headers that are included but not used in audit.c, audit.c,
> policy.c within the IPE module
>
> Change have been tested through kunit, kernel compiles and passes kunit
> tests
>
> Signed-off-by: Yicong Hui <yiconghui@gmail.com>
> ---
> security/ipe/audit.c | 1 -
> security/ipe/policy.c | 1 -
> security/ipe/policy_fs.c | 1 -
> 3 files changed, 3 deletions(-)
...
Hi Yicong,
Thanks for the patch. This kind of cleanup is appreciated.
Commit message typo: "audit. c, audit.c, policy. c" - audit. c is listed
twice.
I was trying to verify whether ipe.h is really not needed and found
that these files are missing explicit dependencies. policy.c and
policy_fs.c use rcu, mutex, and slab functions but rely on transitive
includes. After removing ipe.h, they still compile because eval.h
also happens to provide these dependencies indirectly.
I'm happy to merge a patch removing unused headers like ipe.h, but
would like to see the implicit dependencies resolved as well. Would
you mind tracing the complete dependencies and adding the explicit
includes in v2?
-Fan
^ permalink raw reply
* [PATCH v3 4/4] tpm2-sessions: Open code tpm_buf_append_hmac_session()
From: Jarkko Sakkinen @ 2025-12-03 22:12 UTC (permalink / raw)
To: linux-integrity
Cc: Jarkko Sakkinen, Jonathan McDowell, Peter Huewe, Jason Gunthorpe,
open list, Jarkko Sakkinen, Jonathan McDowell, James Bottomley,
Mimi Zohar, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, open list:KEYS-TRUSTED,
open list:SECURITY SUBSYSTEM
In-Reply-To: <20251203221215.536031-1-jarkko@kernel.org>
From: Jarkko Sakkinen <jarkko.sakkinen@opinsys.com>
Open code 'tpm_buf_append_hmac_session_opt' to the call site, as it only
masks a call sequence and does otherwise nothing particularly useful.
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@opinsys.com>
Reviewed-by: Jonathan McDowell <noodles@meta.com>
---
drivers/char/tpm/tpm2-cmd.c | 14 +++++++++++---
include/linux/tpm.h | 23 -----------------------
security/keys/trusted-keys/trusted_tpm2.c | 12 ++++++++++--
3 files changed, 21 insertions(+), 28 deletions(-)
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index ce0a1c6b0596..3a77be7ebf4a 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -282,9 +282,17 @@ int tpm2_get_random(struct tpm_chip *chip, u8 *dest, size_t max)
do {
tpm_buf_reset(&buf, TPM2_ST_SESSIONS, TPM2_CC_GET_RANDOM);
- tpm_buf_append_hmac_session_opt(chip, &buf, TPM2_SA_ENCRYPT
- | TPM2_SA_CONTINUE_SESSION,
- NULL, 0);
+ if (tpm2_chip_auth(chip)) {
+ tpm_buf_append_hmac_session(chip, &buf,
+ TPM2_SA_ENCRYPT |
+ TPM2_SA_CONTINUE_SESSION,
+ NULL, 0);
+ } else {
+ offset = buf.handles * 4 + TPM_HEADER_SIZE;
+ head = (struct tpm_header *)buf.data;
+ if (tpm_buf_length(&buf) == offset)
+ head->tag = cpu_to_be16(TPM2_ST_NO_SESSIONS);
+ }
tpm_buf_append_u16(&buf, num_bytes);
err = tpm_buf_fill_hmac_session(chip, &buf);
if (err) {
diff --git a/include/linux/tpm.h b/include/linux/tpm.h
index afa51723296a..202da079d500 100644
--- a/include/linux/tpm.h
+++ b/include/linux/tpm.h
@@ -536,29 +536,6 @@ void tpm_buf_append_hmac_session(struct tpm_chip *chip, struct tpm_buf *buf,
int passphraselen);
void tpm_buf_append_auth(struct tpm_chip *chip, struct tpm_buf *buf,
u8 *passphrase, int passphraselen);
-static inline void tpm_buf_append_hmac_session_opt(struct tpm_chip *chip,
- struct tpm_buf *buf,
- u8 attributes,
- u8 *passphrase,
- int passphraselen)
-{
- struct tpm_header *head;
- int offset;
-
- if (tpm2_chip_auth(chip)) {
- tpm_buf_append_hmac_session(chip, buf, attributes, passphrase, passphraselen);
- } else {
- offset = buf->handles * 4 + TPM_HEADER_SIZE;
- head = (struct tpm_header *)buf->data;
-
- /*
- * If the only sessions are optional, the command tag must change to
- * TPM2_ST_NO_SESSIONS.
- */
- if (tpm_buf_length(buf) == offset)
- head->tag = cpu_to_be16(TPM2_ST_NO_SESSIONS);
- }
-}
#ifdef CONFIG_TCG_TPM2_HMAC
diff --git a/security/keys/trusted-keys/trusted_tpm2.c b/security/keys/trusted-keys/trusted_tpm2.c
index 5b205279584b..a7ea4a1c3bed 100644
--- a/security/keys/trusted-keys/trusted_tpm2.c
+++ b/security/keys/trusted-keys/trusted_tpm2.c
@@ -481,8 +481,10 @@ static int tpm2_unseal_cmd(struct tpm_chip *chip,
struct trusted_key_options *options,
u32 blob_handle)
{
+ struct tpm_header *head;
struct tpm_buf buf;
u16 data_len;
+ int offset;
u8 *data;
int rc;
@@ -519,8 +521,14 @@ static int tpm2_unseal_cmd(struct tpm_chip *chip,
tpm2_buf_append_auth(&buf, options->policyhandle,
NULL /* nonce */, 0, 0,
options->blobauth, options->blobauth_len);
- tpm_buf_append_hmac_session_opt(chip, &buf, TPM2_SA_ENCRYPT,
- NULL, 0);
+ if (tpm2_chip_auth(chip)) {
+ tpm_buf_append_hmac_session(chip, &buf, TPM2_SA_ENCRYPT, NULL, 0);
+ } else {
+ offset = buf.handles * 4 + TPM_HEADER_SIZE;
+ head = (struct tpm_header *)buf.data;
+ if (tpm_buf_length(&buf) == offset)
+ head->tag = cpu_to_be16(TPM2_ST_NO_SESSIONS);
+ }
}
rc = tpm_buf_fill_hmac_session(chip, &buf);
--
2.52.0
^ permalink raw reply related
* [PATCH v3 1/4] tpm2-sessions: fix out of range indexing in name_size
From: Jarkko Sakkinen @ 2025-12-03 22:12 UTC (permalink / raw)
To: linux-integrity
Cc: Jarkko Sakkinen, Jonathan McDowell, Peter Huewe, Jason Gunthorpe,
open list, stable, James Bottomley, Mimi Zohar, David Howells,
Paul Moore, James Morris, Serge E. Hallyn, Ard Biesheuvel,
open list:KEYS-TRUSTED, open list:SECURITY SUBSYSTEM
In-Reply-To: <20251203221215.536031-1-jarkko@kernel.org>
'name_size' does not have any range checks, and it just directly indexes
with TPM_ALG_ID, which could lead into memory corruption at worst.
Address the issue by only processing known values and returning -EINVAL for
unrecognized values.
Make also 'tpm_buf_append_name' and 'tpm_buf_fill_hmac_session' fallible so
that errors are detected before causing any spurious TPM traffic.
End also the authorization session on failure in both of the functions, as
the session state would be then by definition corrupted.
Cc: stable@vger.kernel.org # v6.10+
Fixes: 1085b8276bb4 ("tpm: Add the rest of the session HMAC API")
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
v3:
- Fix pr_warn() format string in name_size().
- Fix !CONFIG_TPM2_HMAC compilation.
v2:
- Wrote a better short summary.
- Addressed remarks in https://lore.kernel.org/linux-integrity/aS8TIeviaippVAha@earth.li/
- Use -EIO consistently in tpm2_fill_hmac_session. These are not input value
errors. They could only spun from malformed (kernel) state.
- name_size did not have a proper default-case. Reorganize the
fallback into that.
---
drivers/char/tpm/tpm2-cmd.c | 23 +++-
drivers/char/tpm/tpm2-sessions.c | 133 +++++++++++++++-------
include/linux/tpm.h | 13 ++-
security/keys/trusted-keys/trusted_tpm2.c | 29 ++++-
4 files changed, 143 insertions(+), 55 deletions(-)
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index dd502322f499..be4a9c7f2e1a 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -199,7 +199,11 @@ int tpm2_pcr_extend(struct tpm_chip *chip, u32 pcr_idx,
}
if (!disable_pcr_integrity) {
- tpm_buf_append_name(chip, &buf, pcr_idx, NULL);
+ rc = tpm_buf_append_name(chip, &buf, pcr_idx, NULL);
+ if (rc) {
+ tpm_buf_destroy(&buf);
+ return rc;
+ }
tpm_buf_append_hmac_session(chip, &buf, 0, NULL, 0);
} else {
tpm_buf_append_handle(chip, &buf, pcr_idx);
@@ -214,8 +218,14 @@ int tpm2_pcr_extend(struct tpm_chip *chip, u32 pcr_idx,
chip->allocated_banks[i].digest_size);
}
- if (!disable_pcr_integrity)
- tpm_buf_fill_hmac_session(chip, &buf);
+ if (!disable_pcr_integrity) {
+ rc = tpm_buf_fill_hmac_session(chip, &buf);
+ if (rc) {
+ tpm_buf_destroy(&buf);
+ return rc;
+ }
+ }
+
rc = tpm_transmit_cmd(chip, &buf, 0, "attempting extend a PCR value");
if (!disable_pcr_integrity)
rc = tpm_buf_check_hmac_response(chip, &buf, rc);
@@ -273,7 +283,12 @@ int tpm2_get_random(struct tpm_chip *chip, u8 *dest, size_t max)
| TPM2_SA_CONTINUE_SESSION,
NULL, 0);
tpm_buf_append_u16(&buf, num_bytes);
- tpm_buf_fill_hmac_session(chip, &buf);
+ err = tpm_buf_fill_hmac_session(chip, &buf);
+ if (err) {
+ tpm_buf_destroy(&buf);
+ return err;
+ }
+
err = tpm_transmit_cmd(chip, &buf,
offsetof(struct tpm2_get_random_out,
buffer),
diff --git a/drivers/char/tpm/tpm2-sessions.c b/drivers/char/tpm/tpm2-sessions.c
index 6d03c224e6b2..a265e9752a5e 100644
--- a/drivers/char/tpm/tpm2-sessions.c
+++ b/drivers/char/tpm/tpm2-sessions.c
@@ -144,16 +144,23 @@ struct tpm2_auth {
/*
* Name Size based on TPM algorithm (assumes no hash bigger than 255)
*/
-static u8 name_size(const u8 *name)
+static int name_size(const u8 *name)
{
- static u8 size_map[] = {
- [TPM_ALG_SHA1] = SHA1_DIGEST_SIZE,
- [TPM_ALG_SHA256] = SHA256_DIGEST_SIZE,
- [TPM_ALG_SHA384] = SHA384_DIGEST_SIZE,
- [TPM_ALG_SHA512] = SHA512_DIGEST_SIZE,
- };
- u16 alg = get_unaligned_be16(name);
- return size_map[alg] + 2;
+ u16 hash_alg = get_unaligned_be16(name);
+
+ switch (hash_alg) {
+ case TPM_ALG_SHA1:
+ return SHA1_DIGEST_SIZE + 2;
+ case TPM_ALG_SHA256:
+ return SHA256_DIGEST_SIZE + 2;
+ case TPM_ALG_SHA384:
+ return SHA384_DIGEST_SIZE + 2;
+ case TPM_ALG_SHA512:
+ return SHA512_DIGEST_SIZE + 2;
+ default:
+ pr_warn("tpm: unsupported name algorithm: 0x%04x\n", hash_alg);
+ return -EINVAL;
+ }
}
static int tpm2_parse_read_public(char *name, struct tpm_buf *buf)
@@ -161,6 +168,7 @@ static int tpm2_parse_read_public(char *name, struct tpm_buf *buf)
struct tpm_header *head = (struct tpm_header *)buf->data;
off_t offset = TPM_HEADER_SIZE;
u32 tot_len = be32_to_cpu(head->length);
+ int ret;
u32 val;
/* we're starting after the header so adjust the length */
@@ -172,9 +180,15 @@ static int tpm2_parse_read_public(char *name, struct tpm_buf *buf)
return -EINVAL;
offset += val;
/* name */
+
val = tpm_buf_read_u16(buf, &offset);
- if (val != name_size(&buf->data[offset]))
+ ret = name_size(&buf->data[offset]);
+ if (ret < 0)
+ return ret;
+
+ if (val != ret)
return -EINVAL;
+
memcpy(name, &buf->data[offset], val);
/* forget the rest */
return 0;
@@ -221,46 +235,72 @@ static int tpm2_read_public(struct tpm_chip *chip, u32 handle, char *name)
* As with most tpm_buf operations, success is assumed because failure
* will be caused by an incorrect programming model and indicated by a
* kernel message.
+ *
+ * Ends the authorization session on failure.
*/
-void tpm_buf_append_name(struct tpm_chip *chip, struct tpm_buf *buf,
- u32 handle, u8 *name)
+int tpm_buf_append_name(struct tpm_chip *chip, struct tpm_buf *buf,
+ u32 handle, u8 *name)
{
#ifdef CONFIG_TCG_TPM2_HMAC
enum tpm2_mso_type mso = tpm2_handle_mso(handle);
struct tpm2_auth *auth;
int slot;
+ int ret;
#endif
if (!tpm2_chip_auth(chip)) {
tpm_buf_append_handle(chip, buf, handle);
- return;
+ return 0;
}
#ifdef CONFIG_TCG_TPM2_HMAC
slot = (tpm_buf_length(buf) - TPM_HEADER_SIZE) / 4;
if (slot >= AUTH_MAX_NAMES) {
- dev_err(&chip->dev, "TPM: too many handles\n");
- return;
+ dev_err(&chip->dev, "too many handles\n");
+ ret = -EIO;
+ goto err;
}
auth = chip->auth;
- WARN(auth->session != tpm_buf_length(buf),
- "name added in wrong place\n");
+ if (auth->session != tpm_buf_length(buf)) {
+ dev_err(&chip->dev, "session state malformed");
+ ret = -EIO;
+ goto err;
+ }
tpm_buf_append_u32(buf, handle);
auth->session += 4;
if (mso == TPM2_MSO_PERSISTENT ||
mso == TPM2_MSO_VOLATILE ||
mso == TPM2_MSO_NVRAM) {
- if (!name)
- tpm2_read_public(chip, handle, auth->name[slot]);
+ if (!name) {
+ ret = tpm2_read_public(chip, handle, auth->name[slot]);
+ if (ret)
+ goto err;
+ }
} else {
- if (name)
- dev_err(&chip->dev, "TPM: Handle does not require name but one is specified\n");
+ if (name) {
+ dev_err(&chip->dev, "handle 0x%08x does not use a name\n",
+ handle);
+ ret = -EIO;
+ goto err;
+ }
}
auth->name_h[slot] = handle;
- if (name)
- memcpy(auth->name[slot], name, name_size(name));
+ if (name) {
+ ret = name_size(name);
+ if (ret < 0)
+ goto err;
+
+ memcpy(auth->name[slot], name, ret);
+ }
+#endif
+ return 0;
+
+#ifdef CONFIG_TCG_TPM2_HMAC
+err:
+ tpm2_end_auth_session(chip);
+ return tpm_ret_to_err(ret);
#endif
}
EXPORT_SYMBOL_GPL(tpm_buf_append_name);
@@ -533,11 +573,9 @@ static void tpm_buf_append_salt(struct tpm_buf *buf, struct tpm_chip *chip,
* encryption key and encrypts the first parameter of the command
* buffer with it.
*
- * As with most tpm_buf operations, success is assumed because failure
- * will be caused by an incorrect programming model and indicated by a
- * kernel message.
+ * Ends the authorization session on failure.
*/
-void tpm_buf_fill_hmac_session(struct tpm_chip *chip, struct tpm_buf *buf)
+int tpm_buf_fill_hmac_session(struct tpm_chip *chip, struct tpm_buf *buf)
{
u32 cc, handles, val;
struct tpm2_auth *auth = chip->auth;
@@ -549,9 +587,12 @@ void tpm_buf_fill_hmac_session(struct tpm_chip *chip, struct tpm_buf *buf)
u8 cphash[SHA256_DIGEST_SIZE];
struct sha256_ctx sctx;
struct hmac_sha256_ctx hctx;
+ int ret;
- if (!auth)
- return;
+ if (!auth) {
+ ret = -EIO;
+ goto err;
+ }
/* save the command code in BE format */
auth->ordinal = head->ordinal;
@@ -560,9 +601,11 @@ void tpm_buf_fill_hmac_session(struct tpm_chip *chip, struct tpm_buf *buf)
i = tpm2_find_cc(chip, cc);
if (i < 0) {
- dev_err(&chip->dev, "Command 0x%x not found in TPM\n", cc);
- return;
+ dev_err(&chip->dev, "command 0x%08x not found\n", cc);
+ ret = -EIO;
+ goto err;
}
+
attrs = chip->cc_attrs_tbl[i];
handles = (attrs >> TPM2_CC_ATTR_CHANDLES) & GENMASK(2, 0);
@@ -576,9 +619,9 @@ void tpm_buf_fill_hmac_session(struct tpm_chip *chip, struct tpm_buf *buf)
u32 handle = tpm_buf_read_u32(buf, &offset_s);
if (auth->name_h[i] != handle) {
- dev_err(&chip->dev, "TPM: handle %d wrong for name\n",
- i);
- return;
+ dev_err(&chip->dev, "invalid handle 0x%08x\n", handle);
+ ret = -EIO;
+ goto err;
}
}
/* point offset_s to the start of the sessions */
@@ -609,12 +652,14 @@ void tpm_buf_fill_hmac_session(struct tpm_chip *chip, struct tpm_buf *buf)
offset_s += len;
}
if (offset_s != offset_p) {
- dev_err(&chip->dev, "TPM session length is incorrect\n");
- return;
+ dev_err(&chip->dev, "session length is incorrect\n");
+ ret = -EIO;
+ goto err;
}
if (!hmac) {
- dev_err(&chip->dev, "TPM could not find HMAC session\n");
- return;
+ dev_err(&chip->dev, "could not find HMAC session\n");
+ ret = -EIO;
+ goto err;
}
/* encrypt before HMAC */
@@ -646,8 +691,11 @@ void tpm_buf_fill_hmac_session(struct tpm_chip *chip, struct tpm_buf *buf)
if (mso == TPM2_MSO_PERSISTENT ||
mso == TPM2_MSO_VOLATILE ||
mso == TPM2_MSO_NVRAM) {
- sha256_update(&sctx, auth->name[i],
- name_size(auth->name[i]));
+ ret = name_size(auth->name[i]);
+ if (ret < 0)
+ goto err;
+
+ sha256_update(&sctx, auth->name[i], ret);
} else {
__be32 h = cpu_to_be32(auth->name_h[i]);
@@ -668,6 +716,11 @@ void tpm_buf_fill_hmac_session(struct tpm_chip *chip, struct tpm_buf *buf)
hmac_sha256_update(&hctx, auth->tpm_nonce, sizeof(auth->tpm_nonce));
hmac_sha256_update(&hctx, &auth->attrs, 1);
hmac_sha256_final(&hctx, hmac);
+ return 0;
+
+err:
+ tpm2_end_auth_session(chip);
+ return ret;
}
EXPORT_SYMBOL(tpm_buf_fill_hmac_session);
diff --git a/include/linux/tpm.h b/include/linux/tpm.h
index 3d8f7d1ce2b8..aa816b144ab3 100644
--- a/include/linux/tpm.h
+++ b/include/linux/tpm.h
@@ -529,8 +529,8 @@ static inline struct tpm2_auth *tpm2_chip_auth(struct tpm_chip *chip)
#endif
}
-void tpm_buf_append_name(struct tpm_chip *chip, struct tpm_buf *buf,
- u32 handle, u8 *name);
+int tpm_buf_append_name(struct tpm_chip *chip, struct tpm_buf *buf,
+ u32 handle, u8 *name);
void tpm_buf_append_hmac_session(struct tpm_chip *chip, struct tpm_buf *buf,
u8 attributes, u8 *passphrase,
int passphraselen);
@@ -563,7 +563,7 @@ static inline void tpm_buf_append_hmac_session_opt(struct tpm_chip *chip,
#ifdef CONFIG_TCG_TPM2_HMAC
int tpm2_start_auth_session(struct tpm_chip *chip);
-void tpm_buf_fill_hmac_session(struct tpm_chip *chip, struct tpm_buf *buf);
+int tpm_buf_fill_hmac_session(struct tpm_chip *chip, struct tpm_buf *buf);
int tpm_buf_check_hmac_response(struct tpm_chip *chip, struct tpm_buf *buf,
int rc);
void tpm2_end_auth_session(struct tpm_chip *chip);
@@ -577,10 +577,13 @@ static inline int tpm2_start_auth_session(struct tpm_chip *chip)
static inline void tpm2_end_auth_session(struct tpm_chip *chip)
{
}
-static inline void tpm_buf_fill_hmac_session(struct tpm_chip *chip,
- struct tpm_buf *buf)
+
+static inline int tpm_buf_fill_hmac_session(struct tpm_chip *chip,
+ struct tpm_buf *buf)
{
+ return 0;
}
+
static inline int tpm_buf_check_hmac_response(struct tpm_chip *chip,
struct tpm_buf *buf,
int rc)
diff --git a/security/keys/trusted-keys/trusted_tpm2.c b/security/keys/trusted-keys/trusted_tpm2.c
index 8bc6efa8accb..5b205279584b 100644
--- a/security/keys/trusted-keys/trusted_tpm2.c
+++ b/security/keys/trusted-keys/trusted_tpm2.c
@@ -268,7 +268,10 @@ int tpm2_seal_trusted(struct tpm_chip *chip,
goto out_put;
}
- tpm_buf_append_name(chip, &buf, options->keyhandle, NULL);
+ rc = tpm_buf_append_name(chip, &buf, options->keyhandle, NULL);
+ if (rc)
+ goto out;
+
tpm_buf_append_hmac_session(chip, &buf, TPM2_SA_DECRYPT,
options->keyauth, TPM_DIGEST_SIZE);
@@ -316,7 +319,10 @@ int tpm2_seal_trusted(struct tpm_chip *chip,
goto out;
}
- tpm_buf_fill_hmac_session(chip, &buf);
+ rc = tpm_buf_fill_hmac_session(chip, &buf);
+ if (rc)
+ goto out;
+
rc = tpm_transmit_cmd(chip, &buf, 4, "sealing data");
rc = tpm_buf_check_hmac_response(chip, &buf, rc);
if (rc)
@@ -427,7 +433,10 @@ static int tpm2_load_cmd(struct tpm_chip *chip,
return rc;
}
- tpm_buf_append_name(chip, &buf, options->keyhandle, NULL);
+ rc = tpm_buf_append_name(chip, &buf, options->keyhandle, NULL);
+ if (rc)
+ goto out;
+
tpm_buf_append_hmac_session(chip, &buf, 0, options->keyauth,
TPM_DIGEST_SIZE);
@@ -439,7 +448,10 @@ static int tpm2_load_cmd(struct tpm_chip *chip,
goto out;
}
- tpm_buf_fill_hmac_session(chip, &buf);
+ rc = tpm_buf_fill_hmac_session(chip, &buf);
+ if (rc)
+ goto out;
+
rc = tpm_transmit_cmd(chip, &buf, 4, "loading blob");
rc = tpm_buf_check_hmac_response(chip, &buf, rc);
if (!rc)
@@ -484,7 +496,9 @@ static int tpm2_unseal_cmd(struct tpm_chip *chip,
return rc;
}
- tpm_buf_append_name(chip, &buf, blob_handle, NULL);
+ rc = tpm_buf_append_name(chip, &buf, options->keyhandle, NULL);
+ if (rc)
+ goto out;
if (!options->policyhandle) {
tpm_buf_append_hmac_session(chip, &buf, TPM2_SA_ENCRYPT,
@@ -509,7 +523,10 @@ static int tpm2_unseal_cmd(struct tpm_chip *chip,
NULL, 0);
}
- tpm_buf_fill_hmac_session(chip, &buf);
+ rc = tpm_buf_fill_hmac_session(chip, &buf);
+ if (rc)
+ goto out;
+
rc = tpm_transmit_cmd(chip, &buf, 6, "unsealing");
rc = tpm_buf_check_hmac_response(chip, &buf, rc);
--
2.52.0
^ permalink raw reply related
* Re: set_security_override_from_ctx()
From: Casey Schaufler @ 2025-12-03 22:02 UTC (permalink / raw)
To: LSM List, David Howells; +Cc: SElinux list
In-Reply-To: <cb4293da-41dc-4586-adca-2859944905dc@schaufler-ca.com>
Adding David, who wrote the code ...
On 12/3/2025 1:32 PM, Casey Schaufler wrote:
> While trying to ensure sanity in security context processing I
> discovered set_security_override_from_ctx(), which is not used anywhere
> in the upstream kernel. Does anyone here know what its purpose is? I
> would very much like to remove it, but of course wouldn't want to break
> anything important.
>
>
^ permalink raw reply
* set_security_override_from_ctx()
From: Casey Schaufler @ 2025-12-03 21:32 UTC (permalink / raw)
To: LSM List; +Cc: SElinux list, Casey Schaufler
In-Reply-To: <cb4293da-41dc-4586-adca-2859944905dc.ref@schaufler-ca.com>
While trying to ensure sanity in security context processing I
discovered set_security_override_from_ctx(), which is not used anywhere
in the upstream kernel. Does anyone here know what its purpose is? I
would very much like to remove it, but of course wouldn't want to break
anything important.
^ permalink raw reply
* Re: [PATCH v3 3/5] samples/landlock: Add LANDLOCK_ADD_RULE_NO_INHERIT to landlock-sandboxer
From: Tingmao Wang @ 2025-12-03 21:13 UTC (permalink / raw)
To: Justin Suess
Cc: linux-security-module, Mickaël Salaün,
Günther Noack, Jan Kara, Abhinav Saxena
In-Reply-To: <20251126122039.3832162-4-utilityemal77@gmail.com>
On 11/26/25 12:20, Justin Suess wrote:
> Adds support to landlock-sandboxer with environment variables LL_FS_RO_NO_INHERIT
> and LL_FS_RW_NO_INHERIT. These create the same rulesets as their non-no inherit variants,
> plus the LANDLOCK_ADD_RULE_NO_INHERIT flag.
>
> v2..v3 changes:
>
> * Minor formatting fixes
>
> Signed-off-by: Justin Suess <utilityemal77@gmail.com>
> ---
> samples/landlock/sandboxer.c | 37 +++++++++++++++++++++++++++---------
> 1 file changed, 28 insertions(+), 9 deletions(-)
>
> diff --git a/samples/landlock/sandboxer.c b/samples/landlock/sandboxer.c
> index 2d8e3e94b77b..6f6bfc4e5110 100644
> --- a/samples/landlock/sandboxer.c
> +++ b/samples/landlock/sandboxer.c
> @@ -58,6 +58,8 @@ static inline int landlock_restrict_self(const int ruleset_fd,
>
> #define ENV_FS_RO_NAME "LL_FS_RO"
> #define ENV_FS_RW_NAME "LL_FS_RW"
> +#define ENV_FS_RO_NO_INHERIT_NAME "LL_FS_RO_NO_INHERIT"
> +#define ENV_FS_RW_NO_INHERIT_NAME "LL_FS_RW_NO_INHERIT"
> #define ENV_FS_QUIET_NAME "LL_FS_QUIET"
> #define ENV_FS_QUIET_ACCESS_NAME "LL_FS_QUIET_ACCESS"
> #define ENV_TCP_BIND_NAME "LL_TCP_BIND"
> @@ -121,7 +123,8 @@ static int parse_path(char *env_path, const char ***const path_list)
> /* clang-format on */
>
> static int populate_ruleset_fs(const char *const env_var, const int ruleset_fd,
> - const __u64 allowed_access, bool quiet)
> + const __u64 allowed_access,
> + __u32 add_rule_flags, bool mandatory)
> {
> int num_paths, i, ret = 1;
> char *env_path_name;
> @@ -132,9 +135,13 @@ static int populate_ruleset_fs(const char *const env_var, const int ruleset_fd,
>
> env_path_name = getenv(env_var);
> if (!env_path_name) {
> - /* Prevents users to forget a setting. */
> - fprintf(stderr, "Missing environment variable %s\n", env_var);
> - return 1;
> + if (mandatory) {
> + /* Prevents from forgetting to set necessary env vars. */
> + fprintf(stderr, "Missing environment variable %s\n",
> + env_var);
> + return 1;
> + }
> + return 0;
> }
> env_path_name = strdup(env_path_name);
> unsetenv(env_var);
> @@ -171,8 +178,7 @@ static int populate_ruleset_fs(const char *const env_var, const int ruleset_fd,
> if (!S_ISDIR(statbuf.st_mode))
> path_beneath.allowed_access &= ACCESS_FILE;
> if (landlock_add_rule(ruleset_fd, LANDLOCK_RULE_PATH_BENEATH,
> - &path_beneath,
> - quiet ? LANDLOCK_ADD_RULE_QUIET : 0)) {
> + &path_beneath, add_rule_flags)) {
> fprintf(stderr,
> "Failed to update the ruleset with \"%s\": %s\n",
> path_list[i], strerror(errno));
> @@ -375,6 +381,8 @@ static const char help[] =
> "Optional settings (when not set, their associated access check "
> "is always allowed, which is different from an empty string which "
> "means an empty list):\n"
> + "* " ENV_FS_RO_NO_INHERIT_NAME ": read-only paths without rule inheritance\n"
> + "* " ENV_FS_RW_NO_INHERIT_NAME ": read-write paths without rule inheritance\n"
Would it make more sense to just have one LL_FS_NO_INHERIT env rule, that
will attach the "no inherit" flag without necessarily adding any access?
> "* " ENV_TCP_BIND_NAME ": ports allowed to bind (server)\n"
> "* " ENV_TCP_CONNECT_NAME ": ports allowed to connect (client)\n"
> "* " ENV_SCOPED_NAME ": actions denied on the outside of the landlock domain\n"
> @@ -596,17 +604,28 @@ int main(const int argc, char *const argv[], char *const *const envp)
> }
>
> if (populate_ruleset_fs(ENV_FS_RO_NAME, ruleset_fd, access_fs_ro,
> - false)) {
> + 0, true)) {
> goto err_close_ruleset;
> }
> if (populate_ruleset_fs(ENV_FS_RW_NAME, ruleset_fd, access_fs_rw,
> + 0, true)) {
> + goto err_close_ruleset;
> + }
> + /* Optional no-inherit rules mirror the regular read-only/read-write sets. */
> + if (populate_ruleset_fs(ENV_FS_RO_NO_INHERIT_NAME, ruleset_fd,
> + access_fs_ro, LANDLOCK_ADD_RULE_NO_INHERIT,
> + false)) {
> + goto err_close_ruleset;
> + }
> + if (populate_ruleset_fs(ENV_FS_RW_NO_INHERIT_NAME, ruleset_fd,
> + access_fs_rw, LANDLOCK_ADD_RULE_NO_INHERIT,
These need to be under an ABI version check like the quiet one - this
sandboxer is designed to "downgrade" what it tries to do gracefully if
running on older kernel.
However, there is an argument that maybe if deny rules aren't supported in
the current running kernel, it should just refuse to run the program at
all, otherwise by running the sandboxed program without the deny rules it
might expose the user to risks they might mitigate via some other means.
But in that case we should still have a better error message when running
on an older kernel than "Failed to update the ruleset with ...: Invalid
argument"
> false)) {
> goto err_close_ruleset;
> }
> /* Don't require this env to be present. */
> - if (quiet_supported && getenv(ENV_FS_QUIET_NAME)) {
> + if (quiet_supported) {
> if (populate_ruleset_fs(ENV_FS_QUIET_NAME, ruleset_fd, 0,
> - true)) {
> + LANDLOCK_ADD_RULE_QUIET, false)) {
> goto err_close_ruleset;
> }
> }
^ permalink raw reply
* Re: [PATCH v3 1/5] landlock: Implement LANDLOCK_ADD_RULE_NO_INHERIT
From: Tingmao Wang @ 2025-12-03 21:12 UTC (permalink / raw)
To: Justin Suess, linux-security-module
Cc: Günther Noack, Jan Kara, Abhinav Saxena,
Mickaël Salaün
In-Reply-To: <20251126122039.3832162-2-utilityemal77@gmail.com>
Hi!
I've done a "partial" review of this series (with most of the attention on
this patch). Aside from the comments below, I think we might need to
think a bit more about the implications of things like hard links and bind
mounts, which makes the notion of "parent" non-trivial (as Mickaël also
pointed out on the GitHub thread). However, I think it should mostly be
good. My first pass of reasoning for bind mounts are:
A deny rule does not prevent access through a bind mount if the bind mount
points deep into the denied hierarchy (not to the denied dentry itself),
but does protect it if the bind mount points to the denied dentry itself
or its parent. Therefore, to properly protect a directory that contains
children that might possibly be bind mounted to, a sandboxer just has to
attach deny rules to that directory, plus any bind mounts pointing toward
anything in it, which seems like a reasonable ask given that the sandboxed
application cannot make mounts itself.
Hopefully this review turns out to be useful :)
On 11/26/25 12:20, Justin Suess wrote:
> Implements a flag to prevent access grant inheritance within the filesystem hierarchy
> for landlock rules.
>
> If a landlock rule on an inode has this flag, any access grants on parent inodes will be
> ignored. Moreover, operations that involve altering the direct parent tree of the subject with
I feel like the wording "direct parent tree" is a bit unclear - I think
what you meant is "altering the parent of the subject or its ancestors",
right?
> LANDLOCK_ADD_RULE_NO_INHERIT will be denied up to the mountpoint.
Tbh I'm not entirely clear on why we only deny rename of parents up to the
mountpoint.
>
> Additionally (new in v3) parent flag inheritance is blocked by this flag, allowing fine
> grained access control over LANDLOCK_ADD_RULE_QUIET.
>
> For example, if /a/b/c/ = read only + LANDLOCK_ADD_RULE_NO_INHERIT and / = read write, writes to
> files in /a/b/c will be denied. Moreover, moving /a to /bad, removing /a/b/c, or creating links to
> /a will be prohibited.
>
> And if / has LANDLOCK_ADD_RULE_QUIET, /a/b/c will still audit (handled)
> accesses. This is because LANDLOCK_ADD_RULE_NO_INHERIT also
> suppresses flag inheritance from parent objects.
>
> The parent directory restrictions mitigate sandbox-restart attacks. For example, if a sandboxed program
> is able to move a LANDLOCK_ADD_RULE_NO_INHERIT restricted directory, upon sandbox restart, the policy
> applied naively on the same filenames would be invalid. Preventing these operations mitigates these attacks.
>
> v2..v3 changes:
>
> * Parent directory topology protections now work by lazily
> inserting blank rules on parent inodes if they do not
> exist. This replaces the previous xarray implementation
> with simplified logic.
> * Added an optimization to skip further processing if all layers collected
> no inherit.
> * Added support to block flag inheritance.
>
> Signed-off-by: Justin Suess <utilityemal77@gmail.com>
> ---
> security/landlock/audit.c | 4 +-
> security/landlock/domain.c | 4 +-
> security/landlock/fs.c | 592 +++++++++++++++++++++++++++++++++++-
> security/landlock/ruleset.c | 27 +-
> security/landlock/ruleset.h | 36 ++-
> 5 files changed, 645 insertions(+), 18 deletions(-)
>
> diff --git a/security/landlock/audit.c b/security/landlock/audit.c
> index d51563712325..4da97dd6985c 100644
> --- a/security/landlock/audit.c
> +++ b/security/landlock/audit.c
> @@ -588,7 +588,9 @@ void landlock_log_denial(const struct landlock_cred_security *const subject,
> subject->domain, &missing, request->layer_masks,
> request->layer_masks_size);
> object_quiet_flag = !!(request->rule_flags.quiet_masks &
> - BIT(youngest_layer));
> + BIT(youngest_layer)) &&
> + !(request->rule_flags.blocked_flag_masks &
> + BIT(youngest_layer));
> } else {
> youngest_layer = get_layer_from_deny_masks(
> &missing, request->all_existing_optional_access,
> diff --git a/security/landlock/domain.c b/security/landlock/domain.c
> index 8caf07250328..5bd83865c87d 100644
> --- a/security/landlock/domain.c
> +++ b/security/landlock/domain.c
> @@ -236,7 +236,9 @@ optional_access_t landlock_get_quiet_optional_accesses(
> BITS_PER_TYPE(access_mask_t)) {
> const u8 layer = (deny_masks >> (access_index * 4)) &
> (LANDLOCK_MAX_NUM_LAYERS - 1);
> - const bool is_quiet = !!(rule_flags.quiet_masks & BIT(layer));
> + const layer_mask_t layer_bit = BIT(layer);
> + const bool is_quiet = !!(rule_flags.quiet_masks & layer_bit) &&
> + !(rule_flags.blocked_flag_masks & layer_bit);
>
> if (is_quiet)
> quiet_optional_accesses |= BIT(access_index);
> diff --git a/security/landlock/fs.c b/security/landlock/fs.c
> index 29f10da32141..0a5c73f18f26 100644
> --- a/security/landlock/fs.c
> +++ b/security/landlock/fs.c
> @@ -317,6 +317,206 @@ static struct landlock_object *get_inode_object(struct inode *const inode)
> LANDLOCK_ACCESS_FS_IOCTL_DEV)
> /* clang-format on */
>
> +static const struct landlock_rule *find_rule(const struct landlock_ruleset *const domain,
> + const struct dentry *const dentry);
> +
> +/**
> + * landlock_domain_layers_mask - Build a mask covering all layers of a domain
> + * @domain: The ruleset (domain) to inspect.
> + *
> + * Return a layer mask with a 1 bit for each existing layer of @domain.
> + * If @domain has no layers 0 is returned. If the number of layers is
> + * greater than or equal to the number of bits in layer_mask_t, all bits
> + * are set.
> + */
> +static layer_mask_t landlock_domain_layers_mask(const struct landlock_ruleset
> + *const domain)
> +{
> + if (!domain || !domain->num_layers)
> + return 0;
> +
> + if (domain->num_layers >= sizeof(layer_mask_t) * BITS_PER_BYTE)
> + return (layer_mask_t)~0ULL;
> +
> + return GENMASK_ULL(domain->num_layers - 1, 0);
> +}
> +
> +/**
> + * rule_blocks_all_layers_no_inherit - check whether a rule disables inheritance
> + * @domain_layers_mask: Mask describing the domain's active layers.
> + * @rule: Rule to inspect.
> + *
> + * Return true if every layer present in @rule has its no_inherit flag set
> + * and the set of layers covered by the rule equals @domain_layers_mask.
> + * This indicates that the rule prevents inheritance on all layers of the
> + * domain and thus further walking for inheritance checks can stop.
> + */
> +static bool rule_blocks_all_layers_no_inherit(const layer_mask_t domain_layers_mask,
> + const struct landlock_rule *const rule)
> +{
> + layer_mask_t rule_layers = 0;
> + u32 layer_index;
> +
> + if (!domain_layers_mask || !rule)
> + return false;
> +
> + for (layer_index = 0; layer_index < rule->num_layers; layer_index++) {
> + const struct landlock_layer *const layer =
> + &rule->layers[layer_index];
> + const layer_mask_t layer_bit = BIT_ULL(layer->level - 1);
> +
> + if (!layer->flags.no_inherit)
> + return false;
> +
> + rule_layers |= layer_bit;
> + }
> +
> + return rule_layers && rule_layers == domain_layers_mask;
> +}
> +
> +/**
> + * landlock_collect_no_inherit_layers - Collects layers with no_inherit flags
> + */
Note likely misplaced comment here
> +/**
> + * landlock_collect_no_inherit_layers - collect effective no_inherit layers
> + * @ruleset: Ruleset to consult.
> + * @dentry: Dentry used as a starting point for the upward walk.
> + *
> + * Walk upwards from @dentry and return a layer mask containing the layers
> + * for which either a rule on the visited dentry has the no_inherit flag set
> + * or where an ancestor was previously marked as having a descendant with
> + * a no_inherit rule. The search prefers the closest matching dentry and
> + * stops once any relevant layer bits are found or the root is reached.
> + *
> + * Returns a layer_mask_t where each set bit corresponds to a layer with an
> + * effective no_inherit influence for @dentry. Returns 0 if none apply or if
> + * inputs are invalid.
> + */
> +static layer_mask_t landlock_collect_no_inherit_layers(const struct landlock_ruleset
> + *const ruleset,
> + struct dentry *const dentry)
> +{
> + struct dentry *cursor, *parent;
> + layer_mask_t layers = 0;
> + bool include_descendants = true;
> +
> + if (!ruleset || !dentry || d_is_negative(dentry))
> + return 0;
> +
> + cursor = dget(dentry);
> + while (true) {
> + const struct landlock_rule *rule;
> + u32 layer_index;
> +
> + rule = find_rule(ruleset, cursor);
> + if (rule) {
> + for (layer_index = 0; layer_index < rule->num_layers; layer_index++) {
> + const struct landlock_layer *layer = &rule->layers[layer_index];
> +
> + if (layer->flags.no_inherit ||
> + (include_descendants &&
> + layer->flags.has_no_inherit_descendant))
> + layers |= BIT_ULL((layer->level ?
> + layer->level : layer_index + 1) - 1);
> + }
> + }
> +
> + if (layers) {
> + dput(cursor);
> + return layers;
> + }
> +
> + if (IS_ROOT(cursor)) {
> + dput(cursor);
> + break;
> + }
> +
> + parent = dget_parent(cursor);
> + dput(cursor);
> + if (!parent)
> + break;
> +
> + cursor = parent;
> + include_descendants = false;
> + }
> + return 0;
> +}
> +
> +static int mark_no_inherit_ancestors(struct landlock_ruleset *ruleset,
> + struct dentry *dentry,
> + layer_mask_t descendant_layers);
Wouldn't you be able to avoid this declaration by moving the definition
for ensure_rule_for_dentry and mark_no_inherit_ancestors up a bit, before
mask_no_inherit_descendant_layers?
> +
> +/**
> + * mask_no_inherit_descendant_layers - apply descendant no_inherit masking
> + * @domain: The ruleset (domain) to consult.
> + * @dentry: The dentry whose descendants are considered.
> + * @child_layers: Layers present on the child that may be subject to masking.
> + * @access_request: Accesses being requested (bitmask).
> + * @layer_masks: Per-access layer masks to be modified in-place.
> + * @rule_flags: Collected flags which will be updated accordingly.
> + *
> + * If descendant dentries have no_inherit, clear that
> + * layer's bit from @layer_masks. Also updates @rule_flags to reflect
> + * which layers were blocked. Returns true if any of the @layer_masks were
> + * modified, false otherwise.
> + */
> +static bool mask_no_inherit_descendant_layers(const struct landlock_ruleset
> + *const domain,
> + struct dentry *const dentry,
> + layer_mask_t child_layers,
> + const access_mask_t access_request,
> + layer_mask_t
> + (*const layer_masks)
> + [LANDLOCK_NUM_ACCESS_FS],
> + struct collected_rule_flags
> + *const rule_flags)
> +{
> + layer_mask_t descendant_layers;
> + const unsigned long access_req = access_request;
> + unsigned long access_bit;
> + bool changed = false;
> +
> + if (!access_request || !layer_masks || !rule_flags || !dentry)
> + return false;
> + if (d_is_negative(dentry))
> + return false;
> +
> + descendant_layers = landlock_collect_no_inherit_layers(domain, dentry);
> + {
> + layer_mask_t shared_layers = descendant_layers & child_layers;
> +
> + if (shared_layers) {
> + rule_flags->no_inherit_masks |= shared_layers;
> + rule_flags->no_inherit_desc_masks |= shared_layers;
> + rule_flags->blocked_flag_masks |= shared_layers;
> + }
> + }
> + descendant_layers &= ~child_layers;
> + descendant_layers &= ~rule_flags->no_inherit_masks;
> + if (!descendant_layers)
> + return false;
> +
> + rule_flags->blocked_flag_masks |= descendant_layers;
> +
> + for_each_set_bit(access_bit, &access_req,
> + ARRAY_SIZE(*layer_masks)) {
> + layer_mask_t *const layer_mask = &(*layer_masks)[access_bit];
> +
> + if (*layer_mask & descendant_layers) {
> + *layer_mask &= ~descendant_layers;
> + changed = true;
> + }
> + }
> +
> + if (!changed)
> + return false;
> +
> + rule_flags->no_inherit_masks |= descendant_layers;
> + rule_flags->no_inherit_desc_masks |= descendant_layers;
> +
> + return true;
> +}
> +
> /*
> * @path: Should have been checked by get_path_from_fd().
> */
> @@ -325,12 +525,13 @@ int landlock_append_fs_rule(struct landlock_ruleset *const ruleset,
> access_mask_t access_rights, const int flags)
> {
> int err;
> + const bool is_dir = d_is_dir(path->dentry);
> struct landlock_id id = {
> .type = LANDLOCK_KEY_INODE,
> };
>
> /* Files only get access rights that make sense. */
> - if (!d_is_dir(path->dentry) &&
> + if (!is_dir &&
> (access_rights | ACCESS_FILE) != ACCESS_FILE)
> return -EINVAL;
> if (WARN_ON_ONCE(ruleset->num_layers != 1))
> @@ -344,13 +545,43 @@ int landlock_append_fs_rule(struct landlock_ruleset *const ruleset,
> return PTR_ERR(id.key.object);
> mutex_lock(&ruleset->lock);
> err = landlock_insert_rule(ruleset, id, access_rights, flags);
> + if (!err && (flags & LANDLOCK_ADD_RULE_NO_INHERIT)) {
> + const struct landlock_rule *rule;
> + layer_mask_t descendant_layers = 0;
> + u32 layer_index;
> +
> + rule = find_rule(ruleset, path->dentry);
> + if (rule) {
> + for (layer_index = 0; layer_index < rule->num_layers; layer_index++) {
This function is only called to add rules to an "unmerged" ruleset, which
will always only have one layer. So probably this can just be a
err = landlock_insert_rule(ruleset, id, access_rights, flags);
if (err)
goto out_unlock;
if (flags & LANDLOCK_ADD_RULE_NO_INHERIT) {
err = mark_no_inherit_ancestors(ruleset, path->dentry);
if (err)
goto out_unlock;
}
And for a similar reason, you don't have to do a for(layer_index) in
mark_no_inherit_ancestors either. (Basically I think you would just set
rule->layers[0].flags.has_no_inherit_descendant to true)
It might be helpful to validate / document this reasoning by adding
WARN_ONCE(rule->num_layers != 1, "unmerged rulesets should only have one
layer") either here or in mark_no_inherit_ancestors.
> + const struct landlock_layer *layer =
> + &rule->layers[layer_index];
> +
> + if (layer->flags.no_inherit ||
> + layer->flags.has_no_inherit_descendant)
> + descendant_layers |=
> + BIT_ULL((layer->level ?
> + layer->level : layer_index + 1) - 1);
> + }
> + if (descendant_layers) {
> + err = mark_no_inherit_ancestors(ruleset, path->dentry,
> + descendant_layers);
> + if (err)
> + goto out_unlock;
> + }
> + }
> + }
> mutex_unlock(&ruleset->lock);
> +out:
> /*
> * No need to check for an error because landlock_insert_rule()
> * increments the refcount for the new object if needed.
> */
> landlock_put_object(id.key.object);
> return err;
> +
> +out_unlock:
> + mutex_unlock(&ruleset->lock);
> + goto out;
> }
>
> /* Access-control management */
> @@ -382,6 +613,134 @@ find_rule(const struct landlock_ruleset *const domain,
> return rule;
> }
>
> +/**
> + * ensure_rule_for_dentry - ensure a ruleset contains a rule entry for dentry,
> + * inserting a blank rule if needed.
> + * @ruleset: Ruleset to modify/inspect. Caller must hold @ruleset->lock.
> + * @dentry: Dentry to ensure a rule exists for.
> + *
> + * If no rule is currently associated with @dentry, insert an empty rule
> + * (with zero access) tied to the backing inode. Returns a pointer to the
> + * rule associated with @dentry on success, NULL when @dentry is negative, or
> + * an ERR_PTR()-encoded error if the rule cannot be created.
> + *
> + * This is useful for LANDLOCK_ADD_RULE_NO_INHERIT processing, where a rule
> + * may need to be created for an ancestor dentry that does not yet have one
> + * to properly track no_inherit flags.
> + *
> + * The flags are set to zero if a rule is newly created, and the caller
> + * is responsible for setting them appropriately.
> + *
> + * The returned rule pointer's lifetime is tied to @ruleset.
> + */
> +static const struct landlock_rule *
> +ensure_rule_for_dentry(struct landlock_ruleset *const ruleset,
> + struct dentry *const dentry)
> +{
> + struct landlock_id id = {
> + .type = LANDLOCK_KEY_INODE,
> + };
> + const struct landlock_rule *rule;
> + int err;
> +
> + if (!ruleset || !dentry || d_is_negative(dentry))
> + return NULL;
> +
> + lockdep_assert_held(&ruleset->lock);
> +
> + rule = find_rule(ruleset, dentry);
> + if (rule)
> + return rule;
> +
> + id.key.object = get_inode_object(d_backing_inode(dentry));
> + if (IS_ERR(id.key.object))
> + return ERR_CAST(id.key.object);
> +
> + err = landlock_insert_rule(ruleset, id, 0, 0);
> + landlock_put_object(id.key.object);
> + if (err)
> + return ERR_PTR(err);
> +
> + rule = find_rule(ruleset, dentry);
> + return rule ? rule : ERR_PTR(-ENOENT);
I feel like this deserves a WARN_ON_ONCE(!rule) before this line - we
don't really expect to not find a rule right after adding it.
On the other hand, the only reason why we need to re-lookup the rule seems
to be because landlock_insert_rule() does not return the newly added rule.
We could change it to do so, and not have to do this extra lookup.
This also nicely solves the constness issue - landlock_insert_rule could
return the mutable pointer.
> +}
> +
> +/**
> + * mark_no_inherit_ancestors - mark ancestors as having no_inherit descendants
> + * @ruleset: Ruleset to modify. Caller must hold @ruleset->lock.
> + * @dentry: Dentry representing the descendant that carries no_inherit bits.
> + * @descendant_layers: Mask of layers from the descendant that should be
> + * advertised to ancestors via has_no_inherit_descendant.
> + *
> + * Walks upward from @dentry and ensures that any ancestor rule contains the
> + * has_no_inherit_descendant marker for the specified @descendant_layers so
> + * parent lookups can quickly detect descendant no_inherit influence.
> + *
> + * Returns 0 on success or a negative errno if ancestor bookkeeping fails.
> + */
> +static int mark_no_inherit_ancestors(struct landlock_ruleset *ruleset,
> + struct dentry *dentry,
> + layer_mask_t descendant_layers)
> +{
> + struct dentry *cursor;
> + u32 layer_index;
> + int err = 0;
> +
> + if (!ruleset || !dentry || !descendant_layers)
> + return -EINVAL;
> +
> + lockdep_assert_held(&ruleset->lock);
> +
> + cursor = dget(dentry);
> + while (cursor) {
> + struct dentry *parent;
> +
> + if (IS_ROOT(cursor)) {
> + dput(cursor);
> + break;
> + }
> +
> + parent = dget_parent(cursor);
> + dput(cursor);
> + if (!parent)
> + break;
> +
> + if (!d_is_negative(parent)) {
My understanding is that if the child is not negative (which is required
for us to actually get here), as long as we always have a reference to it,
none of its parents should be negative as well. This should probably be a
WARN_ON_ONCE(d_is_negative(parent)).
I think some of the other d_is_negative() checks in this patch also have a
similar argument (i.e. turn into WARN_ON_ONCE or be removed if not
necessary), but I've not looked at them all.
> + const struct landlock_rule *rule;
> + /* Ensures a rule exists for the parent dentry,
> + * inserting a blank one if needed
> + */
> + rule = ensure_rule_for_dentry(ruleset, parent);
> + if (IS_ERR(rule)) {
> + err = PTR_ERR(rule);
> + dput(parent);
> + cursor = NULL;
> + break;
> + }
> + if (rule) {
> + struct landlock_rule *mutable_rule =
> + (struct landlock_rule *)rule;
> +
> + for (layer_index = 0;
> + layer_index < mutable_rule->num_layers;
> + layer_index++) {
> + struct landlock_layer *layer =
> + &mutable_rule->layers[layer_index];
> + layer_mask_t layer_bit =
> + BIT_ULL((layer->level ?
> + layer->level : layer_index + 1) - 1);
> +
> + if (descendant_layers & layer_bit)
> + layer->flags.has_no_inherit_descendant = true;
> + }
> + }
> + }
> +
> + cursor = parent;
> + }
> + return err;
> +}
> +
> /*
> * Allows access to pseudo filesystems that will never be mountable (e.g.
> * sockfs, pipefs), but can still be reachable through
> @@ -764,6 +1123,8 @@ static bool is_access_to_paths_allowed(
> struct landlock_request *const log_request_parent2,
> struct dentry *const dentry_child2)
> {
> + const layer_mask_t domain_layers_mask =
> + landlock_domain_layers_mask(domain);
> bool allowed_parent1 = false, allowed_parent2 = false, is_dom_check,
> is_dom_check_bkp, child1_is_directory = true,
> child2_is_directory = true;
> @@ -778,6 +1139,13 @@ static bool is_access_to_paths_allowed(
> struct collected_rule_flags *rule_flags_parent1 = &log_request_parent1->rule_flags;
> struct collected_rule_flags *rule_flags_parent2 = &log_request_parent2->rule_flags;
> struct collected_rule_flags _rule_flag_parent1_bkp, _rule_flag_parent2_bkp;
> + layer_mask_t child1_layers = 0;
> + layer_mask_t child2_layers = 0;
> +
> + if (dentry_child1)
> + child1_layers = landlock_collect_no_inherit_layers(domain, dentry_child1);
> + if (dentry_child2)
> + child2_layers = landlock_collect_no_inherit_layers(domain, dentry_child2);
>
> if (!access_request_parent1 && !access_request_parent2)
> return true;
> @@ -931,6 +1299,10 @@ static bool is_access_to_paths_allowed(
> ARRAY_SIZE(*layer_masks_parent2),
> rule_flags_parent2);
>
> + if (rule &&
> + rule_blocks_all_layers_no_inherit(domain_layers_mask, rule))
> + break;
> +
> /* Stops when a rule from each layer grants access. */
> if (allowed_parent1 && allowed_parent2) {
> /*
> @@ -976,8 +1348,13 @@ static bool is_access_to_paths_allowed(
> memcpy(&_rule_flag_parent2_bkp,
> rule_flags_parent2,
> sizeof(_rule_flag_parent2_bkp));
> - is_dom_check_bkp = is_dom_check;
> }
> + is_dom_check_bkp = is_dom_check;
> + child1_layers = landlock_collect_no_inherit_layers(domain,
> + walker_path
> + .dentry);
> + if (layer_masks_parent2)
> + child2_layers = child1_layers;
>
> /* Ignores hidden mount points. */
> goto jump_up;
> @@ -1001,15 +1378,50 @@ static bool is_access_to_paths_allowed(
> break;
> }
>
> - /*
> - * We reached a disconnected root directory from a bind mount, and
> - * we need to reset the walk to the current mount root.
> - */
> - goto reset_to_mount_root;
> - }
> - parent_dentry = dget_parent(walker_path.dentry);
> - dput(walker_path.dentry);
> - walker_path.dentry = parent_dentry;
> + /*
> + * We reached a disconnected root directory from a bind mount, and
> + * we need to reset the walk to the current mount root.
> + */
Accidental change of indentation?
> + goto reset_to_mount_root;
> + }
> + if (likely(!d_is_negative(walker_path.dentry))) {
> + child1_layers = landlock_collect_no_inherit_layers(domain,
> + walker_path.dentry);
> + if (layer_masks_parent2)
> + child2_layers = child1_layers;
> + } else {
> + child1_layers = 0;
> + if (layer_masks_parent2)
> + child2_layers = 0;
> + }
> + parent_dentry = dget_parent(walker_path.dentry);
> + dput(walker_path.dentry);
> + walker_path.dentry = parent_dentry;
> + /*
> + * Apply descendant no-inherit masking now that we've moved to the
> + * parent. This ensures the parent respects any no-inherit rules from
> + * the child we just left. Only applies to refer operations (rename/link).
> + */
> + if (unlikely(layer_masks_parent2)) {
> + if (mask_no_inherit_descendant_layers(domain, walker_path.dentry,
> + child1_layers,
> + access_masked_parent1,
> + layer_masks_parent1,
> + rule_flags_parent1))
> + allowed_parent1 =
> + allowed_parent1 ||
> + is_layer_masks_allowed(layer_masks_parent1);
> +
> + if (rule_flags_parent2 &&
> + mask_no_inherit_descendant_layers(domain, walker_path.dentry,
> + child2_layers,
> + access_masked_parent2,
> + layer_masks_parent2,
> + rule_flags_parent2))
> + allowed_parent2 =
> + allowed_parent2 ||
> + is_layer_masks_allowed(layer_masks_parent2);
> + }
Maybe I'm missing something, but I can't tell what's the purpose of this
block, or in fact what mask_no_inherit_descendant_layers and
landlock_collect_no_inherit_layers is for. The doc comment for
mask_no_inherit_descendant_layers seems to suggest that it's supposed to
walk descendents, but landlock_collect_no_inherit_layers is actually
walking ancestors. Removing these checks doesn't seem to break any tests,
and sandboxer still seems to work as expected wrt. no_inherit rules and
denial of renaming denied dentries and its parents.
Note that the special "reverting" style disconnected directory handling
has been removed in Mickaël's next branch (i.e. the "backup" logic is
removed), which should hopefully simplify reasoning about this.
> continue;
>
> reset_to_mount_root:
> @@ -1057,6 +1469,10 @@ static bool is_access_to_paths_allowed(
> dput(walker_path.dentry);
> walker_path.dentry = walker_path.mnt->mnt_root;
> dget(walker_path.dentry);
> + child1_layers = landlock_collect_no_inherit_layers(domain,
> + walker_path.dentry);
> + if (layer_masks_parent2)
> + child2_layers = child1_layers;
> }
> path_put(&walker_path);
>
> @@ -1172,6 +1588,8 @@ static bool collect_domain_accesses(
> struct collected_rule_flags *const rule_flags)
> {
> access_mask_t access_dom;
> + const layer_mask_t domain_layers_mask =
> + landlock_domain_layers_mask(domain);
> bool ret = false;
>
> if (WARN_ON_ONCE(!domain || !mnt_dir || !dir || !layer_masks_dom))
> @@ -1187,9 +1605,11 @@ static bool collect_domain_accesses(
> while (true) {
> struct dentry *parent_dentry;
>
> + const struct landlock_rule *rule = find_rule(domain, dir);
> +
> /* Gets all layers allowing all domain accesses. */
> if (landlock_unmask_layers(
> - find_rule(domain, dir), access_dom, layer_masks_dom,
> + rule, access_dom, layer_masks_dom,
> ARRAY_SIZE(*layer_masks_dom), rule_flags)) {
> /*
> * Before allowing this side of the access request, checks that the
> @@ -1206,6 +1626,10 @@ static bool collect_domain_accesses(
> break;
> }
>
> + if (rule &&
> + rule_blocks_all_layers_no_inherit(domain_layers_mask, rule))
> + break;
> +
> /* Stops at the mount point. */
> if (dir == mnt_dir->dentry)
> break;
> @@ -1232,6 +1656,121 @@ static bool collect_domain_accesses(
> return ret;
> }
>
> +/**
> + * collect_topology_sealed_layers - collect layers sealed against topology changes
> + * @domain: Ruleset to consult.
> + * @dentry: Starting dentry for the upward walk.
> + * @override_layers: Optional out parameter filled with layers that are
> + * present on ancestors but considered overrides (not
> + * sealing the topology for descendants).
> + *
> + * Walk upwards from @dentry and return a mask of layers where either the
> + * visited dentry contains a no_inherit rule or ancestors were previously
> + * marked as having a descendant with no_inherit. @override_layers, if not
> + * NULL, is filled with layers that would normally be overridden by more
> + * specific descendant rules.
> + *
> + * Returns a layer mask where set bits indicate layers that are "sealed"
> + * (topology changes like rename/rmdir are denied) for the subtree rooted at
> + * @dentry.
> + *
> + * Useful for LANDLOCK_ADD_RULE_NO_INHERIT parent directory enforcement to ensure
> + * that topology changes do not violate the no_inherit constraints.
> + */
> +static layer_mask_t
> +collect_topology_sealed_layers(const struct landlock_ruleset *const domain,
> + struct dentry *dentry,
> + layer_mask_t *const override_layers)
> +{
> + struct dentry *cursor, *parent;
> + bool include_descendants = true;
> + layer_mask_t sealed_layers = 0;
> +
> + if (override_layers)
> + *override_layers = 0;
> +
> + if (!domain || !dentry || d_is_negative(dentry))
> + return 0;
> +
> + cursor = dget(dentry);
> + while (cursor) {
> + const struct landlock_rule *rule;
> + u32 layer_index;
> +
> + rule = find_rule(domain, cursor);
> + if (rule) {
> + for (layer_index = 0; layer_index < rule->num_layers;
> + layer_index++) {
> + const struct landlock_layer *layer =
> + &rule->layers[layer_index];
> + const int level = layer->level ? layer->level :
> + layer_index + 1;
Wouldn't layer->level always be >= 1 here? Using layer_index doesn't make
sense since layer_index is just the index that the struct landlock_layer
happened to be in that rule's array.
> + layer_mask_t layer_bit = BIT_ULL(level - 1);
> +
> + if (include_descendants &&
> + (layer->flags.no_inherit ||
> + layer->flags.has_no_inherit_descendant)) {
> + sealed_layers |= layer_bit;
> + } else if (override_layers) {
> + *override_layers |= layer_bit;
> + }
> + }
> + }
> +
> + if (sealed_layers || IS_ROOT(cursor))
> + break;
> +
> + parent = dget_parent(cursor);
> + dput(cursor);
> + if (!parent)
> + return sealed_layers;
> +
> + cursor = parent;
> + include_descendants = false;
> + }
> + dput(cursor);
> + return sealed_layers;
> +}
> +
> +/**
> + * deny_no_inherit_topology_change - deny topology changes on sealed layers
> + * @subject: Subject performing the operation (contains the domain).
> + * @dentry: Dentry that is the target of the topology modification.
> + *
> + * Checks whether any domain layers are sealed against topology changes at
> + * @dentry (via collect_topology_sealed_layers). If so, emit an audit record
> + * and return -EACCES. Otherwise return 0.
> + */
> +static int deny_no_inherit_topology_change(const struct landlock_cred_security
> + *subject,
> + struct dentry *dentry)
> +{
> + layer_mask_t sealed_layers;
> + layer_mask_t override_layers;
> + unsigned long layer_index;
> +
> + if (!subject || !dentry || d_is_negative(dentry))
> + return 0;
> + sealed_layers = collect_topology_sealed_layers(subject->domain,
> + dentry, &override_layers);
> + sealed_layers &= ~override_layers;
> +
> + if (!sealed_layers)
> + return 0;
> +
> + layer_index = __ffs((unsigned long)sealed_layers);
> + landlock_log_denial(subject, &(struct landlock_request) {
> + .type = LANDLOCK_REQUEST_FS_CHANGE_TOPOLOGY,
> + .audit = {
> + .type = LSM_AUDIT_DATA_DENTRY,
> + .u.dentry = dentry,
> + },
> + .layer_plus_one = layer_index + 1,
> + });
> +
> + return -EACCES;
> +}
> +
> /**
> * current_check_refer_path - Check if a rename or link action is allowed
> *
> @@ -1316,6 +1855,16 @@ static int current_check_refer_path(struct dentry *const old_dentry,
> access_request_parent2 =
> get_mode_access(d_backing_inode(old_dentry)->i_mode);
> if (removable) {
> + int err;
> +
> + err = deny_no_inherit_topology_change(subject, old_dentry);
> + if (err)
> + return err;
> + if (exchange) {
> + err = deny_no_inherit_topology_change(subject, new_dentry);
> + if (err)
> + return err;
> + }
> access_request_parent1 |= maybe_remove(old_dentry);
> access_request_parent2 |= maybe_remove(new_dentry);
> }
> @@ -1707,12 +2256,31 @@ static int hook_path_symlink(const struct path *const dir,
> static int hook_path_unlink(const struct path *const dir,
> struct dentry *const dentry)
> {
> + const struct landlock_cred_security *const subject =
> + landlock_get_applicable_subject(current_cred(), any_fs, NULL);
> + int err;
> +
> + if (subject) {
> + err = deny_no_inherit_topology_change(subject, dentry);
> + if (err)
> + return err;
> + }
> return current_check_access_path(dir, LANDLOCK_ACCESS_FS_REMOVE_FILE);
> }
>
> static int hook_path_rmdir(const struct path *const dir,
> struct dentry *const dentry)
> {
> + const struct landlock_cred_security *const subject =
> + landlock_get_applicable_subject(current_cred(), any_fs, NULL);
> + int err;
> +
> + if (subject) {
> + err = deny_no_inherit_topology_change(subject, dentry);
> + if (err)
> + return err;
> + }
> +
> return current_check_access_path(dir, LANDLOCK_ACCESS_FS_REMOVE_DIR);
> }
>
> diff --git a/security/landlock/ruleset.c b/security/landlock/ruleset.c
> index 750a444e1983..f7b6a48bbf39 100644
> --- a/security/landlock/ruleset.c
> +++ b/security/landlock/ruleset.c
> @@ -255,8 +255,13 @@ static int insert_rule(struct landlock_ruleset *const ruleset,
> return -EINVAL;
> if (WARN_ON_ONCE(this->layers[0].level != 0))
> return -EINVAL;
> + /* Merge the flags into the rules */
> this->layers[0].access |= (*layers)[0].access;
> this->layers[0].flags.quiet |= (*layers)[0].flags.quiet;
> + this->layers[0].flags.no_inherit |=
> + (*layers)[0].flags.no_inherit;
> + this->layers[0].flags.has_no_inherit_descendant |=
> + (*layers)[0].flags.has_no_inherit_descendant;
> return 0;
> }
>
> @@ -315,7 +320,10 @@ int landlock_insert_rule(struct landlock_ruleset *const ruleset,
> .level = 0,
> .flags = {
> .quiet = !!(flags & LANDLOCK_ADD_RULE_QUIET),
> - },
> + .no_inherit = !!(flags & LANDLOCK_ADD_RULE_NO_INHERIT),
> + .has_no_inherit_descendant =
> + !!(flags & LANDLOCK_ADD_RULE_NO_INHERIT),
> + }
> } };
>
> build_check_layer();
> @@ -662,9 +670,22 @@ bool landlock_unmask_layers(const struct landlock_rule *const rule,
> unsigned long access_bit;
> bool is_empty;
>
> - /* Collect rule flags for each layer. */
> - if (rule_flags && layer->flags.quiet)
> + /* Skip layers that already have no inherit flags. */
> + if (rule_flags &&
> + (rule_flags->no_inherit_masks & layer_bit))
> + continue;
> +
> + /* Collect rule flags for each layer.
> + * We block flag inheritance if needed
> + * because of a no_inherit rule.
> + */
> + if (rule_flags && layer->flags.quiet &&
> + !(rule_flags->blocked_flag_masks & layer_bit))
I don't quite understand the purpose of blocked_flag_masks - wouldn't the
"continue;" above naturally prevent flag inheritance?
> rule_flags->quiet_masks |= layer_bit;
> + if (rule_flags && layer->flags.no_inherit)
> + rule_flags->no_inherit_masks |= layer_bit;
> + if (rule_flags && layer->flags.has_no_inherit_descendant)
> + rule_flags->no_inherit_desc_masks |= layer_bit;
>
> /*
> * Records in @layer_masks which layer grants access to each requested
> diff --git a/security/landlock/ruleset.h b/security/landlock/ruleset.h
> index eb60db646422..8b46ab14e995 100644
> --- a/security/landlock/ruleset.h
> +++ b/security/landlock/ruleset.h
> @@ -40,6 +40,21 @@ struct landlock_layer {
> * down the file hierarchy.
> */
> bool quiet:1;
> + /**
> + * @no_inherit: Prevents this rule from being inherited by
> + * descendant directories in the filesystem layer. Only used
> + * for filesystem rules.
> + */
> + bool no_inherit:1;
> + /**
> + * @has_no_inherit_descendant: Marker to indicate that this layer
> + * has at least one descendant directory with a rule having the
> + * no_inherit flag. Only used for filesystem rules.
> + * This "flag" is not set by the user, but by Landlock on
> + * parent directories of rules when the child rule has
> + * a rule with the no_inherit flag.
> + */
> + bool has_no_inherit_descendant:1;
> } flags;
> /**
> * @access: Bitfield of allowed actions on the kernel object. They are
> @@ -49,13 +64,32 @@ struct landlock_layer {
> };
>
> /**
> - * struct collected_rule_flags - Hold accumulated flags for each layer.
> + * struct collected_rule_flags - Hold accumulated flags and their markers for each layer.
> */
> struct collected_rule_flags {
> /**
> * @quiet_masks: Layers for which the quiet flag is effective.
> */
> layer_mask_t quiet_masks;
> + /**
> + * @no_inherit_masks: Layers for which the no_inherit flag is effective.
> + */
> + layer_mask_t no_inherit_masks;
> + /**
> + * @no_inherit_desc_masks: Layers for which the
> + * has_no_inherit_descendant tag is effective.
> + * This is not a flag itself, but a marker set on ancestors
> + * of rules with the no_inherit flag to deny topology changes
> + * in the direct parent path.
> + */
> + layer_mask_t no_inherit_desc_masks;
> + /**
> + * @blocked_flag_masks: Layers where flag inheritance must be blocked
> + * because of a no_inherit rule. This is not a flag itself, but a marker
> + * for layers that have their flags blocked due to no_inherit rule
> + * propagation.
> + */
> + layer_mask_t blocked_flag_masks;
> };
>
> /**
^ permalink raw reply
* Re: [PATCH v2] security,fs,nfs,net: update security_inode_listsecurity() interface
From: Stephen Smalley @ 2025-12-03 20:01 UTC (permalink / raw)
To: Paul Moore
Cc: Anna Schumaker, Trond Myklebust, Anna Schumaker, Jakub Kicinski,
Casey Schaufler, Alexander Viro, Christian Brauner, Jan Kara,
James Morris, Serge E. Hallyn, Eric Dumazet, Paolo Abeni,
Willem de Bruijn, David S. Miller, Simon Horman, Ondrej Mosnacek,
linux-nfs, linux-kernel, linux-fsdevel, linux-security-module,
netdev, selinux
In-Reply-To: <CAEjxPJ6e8z__=MP5NfdUxkOMQ=EnUFSjWFofP4YPwHqK=Ki5nw@mail.gmail.com>
On Wed, Dec 3, 2025 at 1:08 PM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Wed, Dec 3, 2025 at 10:55 AM Paul Moore <paul@paul-moore.com> wrote:
> >
> > On Wed, Dec 3, 2025 at 10:35 AM Stephen Smalley
> > <stephen.smalley.work@gmail.com> wrote:
> > > On Wed, Jul 23, 2025 at 10:10 PM Paul Moore <paul@paul-moore.com> wrote:
> > > > On Thu, Jun 19, 2025 at 5:18 PM Paul Moore <paul@paul-moore.com> wrote:
> > > > > On Tue, May 27, 2025 at 5:03 PM Anna Schumaker
> > > > > <anna.schumaker@oracle.com> wrote:
> > > > > > On 5/20/25 5:31 PM, Paul Moore wrote:
> > > > > > > On Tue, Apr 29, 2025 at 7:34 PM Paul Moore <paul@paul-moore.com> wrote:
> > > > > > >> On Mon, Apr 28, 2025 at 4:15 PM Stephen Smalley
> > > > > > >> <stephen.smalley.work@gmail.com> wrote:
> > > > > > >>>
> > > > > > >>> Update the security_inode_listsecurity() interface to allow
> > > > > > >>> use of the xattr_list_one() helper and update the hook
> > > > > > >>> implementations.
> > > > > > >>>
> > > > > > >>> Link: https://lore.kernel.org/selinux/20250424152822.2719-1-stephen.smalley.work@gmail.com/
> > > > > > >>>
> > > > > > >>> Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>
> > > > > > >>> ---
> > > > > > >>> This patch is relative to the one linked above, which in theory is on
> > > > > > >>> vfs.fixes but doesn't appear to have been pushed when I looked.
> > > > > > >>>
> > > > > > >>> fs/nfs/nfs4proc.c | 10 ++++++----
> > > > > > >>> fs/xattr.c | 19 +++++++------------
> > > > > > >>> include/linux/lsm_hook_defs.h | 4 ++--
> > > > > > >>> include/linux/security.h | 5 +++--
> > > > > > >>> net/socket.c | 17 +++++++----------
> > > > > > >>> security/security.c | 16 ++++++++--------
> > > > > > >>> security/selinux/hooks.c | 10 +++-------
> > > > > > >>> security/smack/smack_lsm.c | 13 ++++---------
> > > > > > >>> 8 files changed, 40 insertions(+), 54 deletions(-)
> > > > > > >>
> > > > > > >> Thanks Stephen. Once we get ACKs from the NFS, netdev, and Smack
> > > > > > >> folks I can pull this into the LSM tree.
> > > > > > >
> > > > > > > Gentle ping for Trond, Anna, Jakub, and Casey ... can I get some ACKs
> > > > > > > on this patch? It's a little late for the upcoming merge window, but
> > > > > > > I'd like to merge this via the LSM tree after the merge window closes.
> > > > > >
> > > > > > For the NFS change:
> > > > > > Acked-by: Anna Schumaker <anna.schumaker@oracle.com>
> > > > >
> > > > > Hi Anna,
> > > > >
> > > > > Thanks for reviewing the patch. Unfortunately when merging the patch
> > > > > today and fixing up some merge conflicts I bumped into an odd case in
> > > > > the NFS space and I wanted to check with you on how you would like to
> > > > > resolve it.
> > > > >
> > > > > Commit 243fea134633 ("NFSv4.2: fix listxattr to return selinux
> > > > > security label")[1] adds a direct call to
> > > > > security_inode_listsecurity() in nfs4_listxattr(), despite the
> > > > > existing nfs4_listxattr_nfs4_label() call which calls into the same
> > > > > LSM hook, although that call is conditional on the server supporting
> > > > > NFS_CAP_SECURITY_LABEL. Based on a quick search, it appears the only
> > > > > caller for nfs4_listxattr_nfs4_label() is nfs4_listxattr() so I'm
> > > > > wondering if there isn't some room for improvement here.
> > > > >
> > > > > I think there are two obvious options, and I'm curious about your
> > > > > thoughts on which of these you would prefer, or if there is another
> > > > > third option that you would like to see merged.
> > > > >
> > > > > Option #1:
> > > > > Essentially back out commit 243fea134633, removing the direct LSM call
> > > > > in nfs4_listxattr() and relying on the nfs4_listxattr_nfs4_label() for
> > > > > the LSM/SELinux xattrs. I think we would want to remove the
> > > > > NFS_CAP_SECURITY_LABEL check and build nfs4_listxattr_nfs4_label()
> > > > > regardless of CONFIG_NFS_V4_SECURITY_LABEL.
> > > > >
> > > > > Option #2:
> > > > > Remove nfs4_listxattr_nfs4_label() entirely and keep the direct LSM
> > > > > call in nfs4_listxattr(), with the required changes for this patch.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > [1] https://lore.kernel.org/all/20250425180921.86702-1-okorniev@redhat.com/
> > > >
> > > > A gentle ping on the question above for the NFS folks. If I don't
> > > > hear anything I'll hack up something and send it out for review, but I
> > > > thought it would nice if we could sort out the proper fix first.
> > >
> > > Raising this thread back up again to see if the NFS folks have a
> > > preference on option #1 or #2 above, or
> > > something else altogether. Should returning of the security.selinux
> > > xattr name from listxattr() be dependent on
> > > NFS_CAP_SECURITY_LABEL being set by the server and should it be
> > > dependent on CONFIG_NFS_V4_SECURITY_LABEL?
> >
> > Thanks for bringing this back up Stephen, it would be good to get this resolved.
>
> On second look, I realized that commit 243fea134633 ("NFSv4.2: fix
> listxattr to return selinux security label") was likely motivated by
> the same issue as commit 8b0ba61df5a1c44e2b3cf6 ("fs/xattr.c: fix
> simple_xattr_list to always include security.* xattrs"), i.e. the
> coreutils change that switched ls -Z from unconditionally calling
> getxattr("security.selinux") (via libselinux getfilecon(3)) to only
> doing so if listxattr() returns the "security.selinux" xattr name.
> Hence, we want the call to security_inode_listsecurity() to be
> unconditional, which favors option #2. My only residual question
> though is that commit 243fea134633 put the call _after_ fetching the
> user.* xattr names, whereas the nfs4_listxattr_nfs4_label() returns it
> _before_ any user.* xattrs are appended. I'd be inclined to move up
> the security_inode_listsecurity() call to replace the
> nfs4_listxattr_nfs4_label() call along with option #2.
I've made an attempt to unify the two security_inode_listsecurity()
hook calls in the nfs4 code into a single, unconditional call from
nfs4_listxattr(), which can be found here:
https://lore.kernel.org/selinux/20251203195728.8592-1-stephen.smalley.work@gmail.com/T/#u
If this is deemed acceptable by the NFS folks, then I can re-base this
patch on top of that one.
^ permalink raw reply
* [PATCH] nfs: unify security_inode_listsecurity() calls
From: Stephen Smalley @ 2025-12-03 19:57 UTC (permalink / raw)
To: trondmy, anna
Cc: paul, okorniev, linux-nfs, linux-security-module, selinux,
Stephen Smalley
commit 243fea134633 ("NFSv4.2: fix listxattr to return selinux
security label") introduced a direct call to
security_inode_listsecurity() in nfs4_listxattr(). However,
nfs4_listxattr() already indirectly called
security_inode_listsecurity() via nfs4_listxattr_nfs4_label() if
CONFIG_NFS_V4_SECURITY_LABEL is enabled and the server has the
NFS_CAP_SECURITY_LABEL capability enabled. This duplication was fixed
by commit 9acb237deff7 ("NFSv4.2: another fix for listxattr") by
making the second call conditional on NFS_CAP_SECURITY_LABEL not being
set by the server. However, the combination of the two changes
effectively makes one call to security_inode_listsecurity() in every
case - which is the desired behavior since getxattr() always returns a
security xattr even if it has to synthesize one. Further, the two
different calls produce different xattr name ordering between
security.* and user.* xattr names. Unify the two separate calls into a
single call and get rid of nfs4_listxattr_nfs4_label() altogether.
Link: https://lore.kernel.org/selinux/CAEjxPJ6e8z__=MP5NfdUxkOMQ=EnUFSjWFofP4YPwHqK=Ki5nw@mail.gmail.com/
Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>
---
fs/nfs/nfs4proc.c | 38 +++-----------------------------------
1 file changed, 3 insertions(+), 35 deletions(-)
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 93c6ce04332b..441d4477d789 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -8072,33 +8072,12 @@ static int nfs4_xattr_get_nfs4_label(const struct xattr_handler *handler,
return -EOPNOTSUPP;
}
-static ssize_t
-nfs4_listxattr_nfs4_label(struct inode *inode, char *list, size_t list_len)
-{
- int len = 0;
-
- if (nfs_server_capable(inode, NFS_CAP_SECURITY_LABEL)) {
- len = security_inode_listsecurity(inode, list, list_len);
- if (len >= 0 && list_len && len > list_len)
- return -ERANGE;
- }
- return len;
-}
-
static const struct xattr_handler nfs4_xattr_nfs4_label_handler = {
.prefix = XATTR_SECURITY_PREFIX,
.get = nfs4_xattr_get_nfs4_label,
.set = nfs4_xattr_set_nfs4_label,
};
-#else
-
-static ssize_t
-nfs4_listxattr_nfs4_label(struct inode *inode, char *list, size_t list_len)
-{
- return 0;
-}
-
#endif
#ifdef CONFIG_NFS_V4_2
@@ -10893,7 +10872,7 @@ const struct nfs4_minor_version_ops *nfs_v4_minor_ops[] = {
static ssize_t nfs4_listxattr(struct dentry *dentry, char *list, size_t size)
{
- ssize_t error, error2, error3, error4 = 0;
+ ssize_t error, error2, error3;
size_t left = size;
error = generic_listxattr(dentry, list, left);
@@ -10904,10 +10883,9 @@ static ssize_t nfs4_listxattr(struct dentry *dentry, char *list, size_t size)
left -= error;
}
- error2 = nfs4_listxattr_nfs4_label(d_inode(dentry), list, left);
+ error2 = security_inode_listsecurity(d_inode(dentry), list, left);
if (error2 < 0)
return error2;
-
if (list) {
list += error2;
left -= error2;
@@ -10916,18 +10894,8 @@ static ssize_t nfs4_listxattr(struct dentry *dentry, char *list, size_t size)
error3 = nfs4_listxattr_nfs4_user(d_inode(dentry), list, left);
if (error3 < 0)
return error3;
- if (list) {
- list += error3;
- left -= error3;
- }
-
- if (!nfs_server_capable(d_inode(dentry), NFS_CAP_SECURITY_LABEL)) {
- error4 = security_inode_listsecurity(d_inode(dentry), list, left);
- if (error4 < 0)
- return error4;
- }
- error += error2 + error3 + error4;
+ error += error2 + error3;
if (size && error > size)
return -ERANGE;
return error;
--
2.52.0
^ permalink raw reply related
* [PATCH] ipe: remove headers that are included but not used
From: Yicong Hui @ 2025-12-03 19:37 UTC (permalink / raw)
To: wufan, paul, jmorris, serge
Cc: Yicong Hui, linux-security-module, linux-kernel
Remove headers that are included but not used in audit.c, audit.c,
policy.c within the IPE module
Change have been tested through kunit, kernel compiles and passes kunit
tests
Signed-off-by: Yicong Hui <yiconghui@gmail.com>
---
security/ipe/audit.c | 1 -
security/ipe/policy.c | 1 -
security/ipe/policy_fs.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/security/ipe/audit.c b/security/ipe/audit.c
index de5fed62592e..5064f2257e32 100644
--- a/security/ipe/audit.c
+++ b/security/ipe/audit.c
@@ -8,7 +8,6 @@
#include <linux/types.h>
#include <crypto/sha2.h>
-#include "ipe.h"
#include "eval.h"
#include "hooks.h"
#include "policy.h"
diff --git a/security/ipe/policy.c b/security/ipe/policy.c
index 1c58c29886e8..fe7e8c571ab3 100644
--- a/security/ipe/policy.c
+++ b/security/ipe/policy.c
@@ -6,7 +6,6 @@
#include <linux/errno.h>
#include <linux/verification.h>
-#include "ipe.h"
#include "eval.h"
#include "fs.h"
#include "policy.h"
diff --git a/security/ipe/policy_fs.c b/security/ipe/policy_fs.c
index 9d92d8a14b13..90c37949378c 100644
--- a/security/ipe/policy_fs.c
+++ b/security/ipe/policy_fs.c
@@ -8,7 +8,6 @@
#include <linux/dcache.h>
#include <linux/security.h>
-#include "ipe.h"
#include "policy.h"
#include "eval.h"
#include "fs.h"
--
2.52.0
^ permalink raw reply related
* Re: [GIT PULL] IPE update for 6.19
From: pr-tracker-bot @ 2025-12-03 19:32 UTC (permalink / raw)
To: Fan Wu
Cc: torvalds, linux-security-module, Linux Kernel Mailing List,
Borislav Petkov (AMD), Yanzhu Huang
In-Reply-To: <CAKtyLkEcKAnhdmHb24A2BGGckhjBJANb6XruAmo9L0CBjUMKzA@mail.gmail.com>
The pull request you sent on Tue, 2 Dec 2025 20:01:24 -0800:
> git://git.kernel.org/pub/scm/linux/kernel/git/wufan/ipe.git tags/ipe-pr-20251202
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c8321831480d80af01ce001bd6626fc130fd13b1
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL] selinux/selinux-pr-20251201
From: pr-tracker-bot @ 2025-12-03 19:32 UTC (permalink / raw)
To: Paul Moore; +Cc: Linus Torvalds, selinux, linux-security-module, linux-kernel
In-Reply-To: <c48b683b30a44eb12a0ff032876386fd@paul-moore.com>
The pull request you sent on Mon, 01 Dec 2025 21:00:42 -0500:
> https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git tags/selinux-pr-20251201
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/51e3b98d737aa3e76e077db77b9aa749436c93ac
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-20251201
From: pr-tracker-bot @ 2025-12-03 19:32 UTC (permalink / raw)
To: Paul Moore; +Cc: Linus Torvalds, linux-security-module, linux-kernel
In-Reply-To: <b60d63f8bd01d8432b9986d8a4797f4b@paul-moore.com>
The pull request you sent on Mon, 01 Dec 2025 21:00:34 -0500:
> https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git tags/lsm-pr-20251201
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/121cc35cfb55ab0bcf04c8ba6b364a0990eb2449
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL] Smack patches for 6.19
From: pr-tracker-bot @ 2025-12-03 19:32 UTC (permalink / raw)
To: Casey Schaufler
Cc: Linus Torvalds, LSM List, Linux kernel mailing list,
Casey Schaufler, Konstantin Andreev
In-Reply-To: <80229bac-c3d9-4c99-9cca-dade23ef7421@schaufler-ca.com>
The pull request you sent on Sat, 29 Nov 2025 12:24:38 -0800:
> https://github.com/cschaufler/smack-next tags/Smack-for-6.19
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/204a920f284e7264aa6dcd5876cbb1e03a7e4ebc
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL] KEYS: trusted: keys-trusted-next-rc1
From: pr-tracker-bot @ 2025-12-03 19:32 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: Linus Torvalds, David Howells, James Bottomley, Mimi Zohar,
keyrings, linux-integrity, linux-security-module
In-Reply-To: <aSthHCovbsDZANsa@kernel.org>
The pull request you sent on Sat, 29 Nov 2025 23:09:48 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git tags/keys-trusted-next-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7fc2cd2e4b398c57c9cf961cfea05eadbf34c05c
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH v2] security,fs,nfs,net: update security_inode_listsecurity() interface
From: Stephen Smalley @ 2025-12-03 18:08 UTC (permalink / raw)
To: Paul Moore
Cc: Anna Schumaker, Trond Myklebust, Anna Schumaker, Jakub Kicinski,
Casey Schaufler, Alexander Viro, Christian Brauner, Jan Kara,
James Morris, Serge E. Hallyn, Eric Dumazet, Paolo Abeni,
Willem de Bruijn, David S. Miller, Simon Horman, Ondrej Mosnacek,
linux-nfs, linux-kernel, linux-fsdevel, linux-security-module,
netdev, selinux
In-Reply-To: <CAHC9VhQDHTNkrB4YuNoafM0bhAav=CP5Ux6ZZGY9+WF0+0_9ww@mail.gmail.com>
On Wed, Dec 3, 2025 at 10:55 AM Paul Moore <paul@paul-moore.com> wrote:
>
> On Wed, Dec 3, 2025 at 10:35 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> > On Wed, Jul 23, 2025 at 10:10 PM Paul Moore <paul@paul-moore.com> wrote:
> > > On Thu, Jun 19, 2025 at 5:18 PM Paul Moore <paul@paul-moore.com> wrote:
> > > > On Tue, May 27, 2025 at 5:03 PM Anna Schumaker
> > > > <anna.schumaker@oracle.com> wrote:
> > > > > On 5/20/25 5:31 PM, Paul Moore wrote:
> > > > > > On Tue, Apr 29, 2025 at 7:34 PM Paul Moore <paul@paul-moore.com> wrote:
> > > > > >> On Mon, Apr 28, 2025 at 4:15 PM Stephen Smalley
> > > > > >> <stephen.smalley.work@gmail.com> wrote:
> > > > > >>>
> > > > > >>> Update the security_inode_listsecurity() interface to allow
> > > > > >>> use of the xattr_list_one() helper and update the hook
> > > > > >>> implementations.
> > > > > >>>
> > > > > >>> Link: https://lore.kernel.org/selinux/20250424152822.2719-1-stephen.smalley.work@gmail.com/
> > > > > >>>
> > > > > >>> Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>
> > > > > >>> ---
> > > > > >>> This patch is relative to the one linked above, which in theory is on
> > > > > >>> vfs.fixes but doesn't appear to have been pushed when I looked.
> > > > > >>>
> > > > > >>> fs/nfs/nfs4proc.c | 10 ++++++----
> > > > > >>> fs/xattr.c | 19 +++++++------------
> > > > > >>> include/linux/lsm_hook_defs.h | 4 ++--
> > > > > >>> include/linux/security.h | 5 +++--
> > > > > >>> net/socket.c | 17 +++++++----------
> > > > > >>> security/security.c | 16 ++++++++--------
> > > > > >>> security/selinux/hooks.c | 10 +++-------
> > > > > >>> security/smack/smack_lsm.c | 13 ++++---------
> > > > > >>> 8 files changed, 40 insertions(+), 54 deletions(-)
> > > > > >>
> > > > > >> Thanks Stephen. Once we get ACKs from the NFS, netdev, and Smack
> > > > > >> folks I can pull this into the LSM tree.
> > > > > >
> > > > > > Gentle ping for Trond, Anna, Jakub, and Casey ... can I get some ACKs
> > > > > > on this patch? It's a little late for the upcoming merge window, but
> > > > > > I'd like to merge this via the LSM tree after the merge window closes.
> > > > >
> > > > > For the NFS change:
> > > > > Acked-by: Anna Schumaker <anna.schumaker@oracle.com>
> > > >
> > > > Hi Anna,
> > > >
> > > > Thanks for reviewing the patch. Unfortunately when merging the patch
> > > > today and fixing up some merge conflicts I bumped into an odd case in
> > > > the NFS space and I wanted to check with you on how you would like to
> > > > resolve it.
> > > >
> > > > Commit 243fea134633 ("NFSv4.2: fix listxattr to return selinux
> > > > security label")[1] adds a direct call to
> > > > security_inode_listsecurity() in nfs4_listxattr(), despite the
> > > > existing nfs4_listxattr_nfs4_label() call which calls into the same
> > > > LSM hook, although that call is conditional on the server supporting
> > > > NFS_CAP_SECURITY_LABEL. Based on a quick search, it appears the only
> > > > caller for nfs4_listxattr_nfs4_label() is nfs4_listxattr() so I'm
> > > > wondering if there isn't some room for improvement here.
> > > >
> > > > I think there are two obvious options, and I'm curious about your
> > > > thoughts on which of these you would prefer, or if there is another
> > > > third option that you would like to see merged.
> > > >
> > > > Option #1:
> > > > Essentially back out commit 243fea134633, removing the direct LSM call
> > > > in nfs4_listxattr() and relying on the nfs4_listxattr_nfs4_label() for
> > > > the LSM/SELinux xattrs. I think we would want to remove the
> > > > NFS_CAP_SECURITY_LABEL check and build nfs4_listxattr_nfs4_label()
> > > > regardless of CONFIG_NFS_V4_SECURITY_LABEL.
> > > >
> > > > Option #2:
> > > > Remove nfs4_listxattr_nfs4_label() entirely and keep the direct LSM
> > > > call in nfs4_listxattr(), with the required changes for this patch.
> > > >
> > > > Thoughts?
> > > >
> > > > [1] https://lore.kernel.org/all/20250425180921.86702-1-okorniev@redhat.com/
> > >
> > > A gentle ping on the question above for the NFS folks. If I don't
> > > hear anything I'll hack up something and send it out for review, but I
> > > thought it would nice if we could sort out the proper fix first.
> >
> > Raising this thread back up again to see if the NFS folks have a
> > preference on option #1 or #2 above, or
> > something else altogether. Should returning of the security.selinux
> > xattr name from listxattr() be dependent on
> > NFS_CAP_SECURITY_LABEL being set by the server and should it be
> > dependent on CONFIG_NFS_V4_SECURITY_LABEL?
>
> Thanks for bringing this back up Stephen, it would be good to get this resolved.
On second look, I realized that commit 243fea134633 ("NFSv4.2: fix
listxattr to return selinux security label") was likely motivated by
the same issue as commit 8b0ba61df5a1c44e2b3cf6 ("fs/xattr.c: fix
simple_xattr_list to always include security.* xattrs"), i.e. the
coreutils change that switched ls -Z from unconditionally calling
getxattr("security.selinux") (via libselinux getfilecon(3)) to only
doing so if listxattr() returns the "security.selinux" xattr name.
Hence, we want the call to security_inode_listsecurity() to be
unconditional, which favors option #2. My only residual question
though is that commit 243fea134633 put the call _after_ fetching the
user.* xattr names, whereas the nfs4_listxattr_nfs4_label() returns it
_before_ any user.* xattrs are appended. I'd be inclined to move up
the security_inode_listsecurity() call to replace the
nfs4_listxattr_nfs4_label() call along with option #2.
^ permalink raw reply
* Re: [PATCH v2] security,fs,nfs,net: update security_inode_listsecurity() interface
From: Paul Moore @ 2025-12-03 15:55 UTC (permalink / raw)
To: Stephen Smalley
Cc: Anna Schumaker, Trond Myklebust, Anna Schumaker, Jakub Kicinski,
Casey Schaufler, Alexander Viro, Christian Brauner, Jan Kara,
James Morris, Serge E. Hallyn, Eric Dumazet, Paolo Abeni,
Willem de Bruijn, David S. Miller, Simon Horman, Ondrej Mosnacek,
linux-nfs, linux-kernel, linux-fsdevel, linux-security-module,
netdev, selinux
In-Reply-To: <CAEjxPJ7_7_Uru3dwXzNLSj5GdBTzdPDQr5RwXtdjvDv9GjmVAQ@mail.gmail.com>
On Wed, Dec 3, 2025 at 10:35 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
> On Wed, Jul 23, 2025 at 10:10 PM Paul Moore <paul@paul-moore.com> wrote:
> > On Thu, Jun 19, 2025 at 5:18 PM Paul Moore <paul@paul-moore.com> wrote:
> > > On Tue, May 27, 2025 at 5:03 PM Anna Schumaker
> > > <anna.schumaker@oracle.com> wrote:
> > > > On 5/20/25 5:31 PM, Paul Moore wrote:
> > > > > On Tue, Apr 29, 2025 at 7:34 PM Paul Moore <paul@paul-moore.com> wrote:
> > > > >> On Mon, Apr 28, 2025 at 4:15 PM Stephen Smalley
> > > > >> <stephen.smalley.work@gmail.com> wrote:
> > > > >>>
> > > > >>> Update the security_inode_listsecurity() interface to allow
> > > > >>> use of the xattr_list_one() helper and update the hook
> > > > >>> implementations.
> > > > >>>
> > > > >>> Link: https://lore.kernel.org/selinux/20250424152822.2719-1-stephen.smalley.work@gmail.com/
> > > > >>>
> > > > >>> Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>
> > > > >>> ---
> > > > >>> This patch is relative to the one linked above, which in theory is on
> > > > >>> vfs.fixes but doesn't appear to have been pushed when I looked.
> > > > >>>
> > > > >>> fs/nfs/nfs4proc.c | 10 ++++++----
> > > > >>> fs/xattr.c | 19 +++++++------------
> > > > >>> include/linux/lsm_hook_defs.h | 4 ++--
> > > > >>> include/linux/security.h | 5 +++--
> > > > >>> net/socket.c | 17 +++++++----------
> > > > >>> security/security.c | 16 ++++++++--------
> > > > >>> security/selinux/hooks.c | 10 +++-------
> > > > >>> security/smack/smack_lsm.c | 13 ++++---------
> > > > >>> 8 files changed, 40 insertions(+), 54 deletions(-)
> > > > >>
> > > > >> Thanks Stephen. Once we get ACKs from the NFS, netdev, and Smack
> > > > >> folks I can pull this into the LSM tree.
> > > > >
> > > > > Gentle ping for Trond, Anna, Jakub, and Casey ... can I get some ACKs
> > > > > on this patch? It's a little late for the upcoming merge window, but
> > > > > I'd like to merge this via the LSM tree after the merge window closes.
> > > >
> > > > For the NFS change:
> > > > Acked-by: Anna Schumaker <anna.schumaker@oracle.com>
> > >
> > > Hi Anna,
> > >
> > > Thanks for reviewing the patch. Unfortunately when merging the patch
> > > today and fixing up some merge conflicts I bumped into an odd case in
> > > the NFS space and I wanted to check with you on how you would like to
> > > resolve it.
> > >
> > > Commit 243fea134633 ("NFSv4.2: fix listxattr to return selinux
> > > security label")[1] adds a direct call to
> > > security_inode_listsecurity() in nfs4_listxattr(), despite the
> > > existing nfs4_listxattr_nfs4_label() call which calls into the same
> > > LSM hook, although that call is conditional on the server supporting
> > > NFS_CAP_SECURITY_LABEL. Based on a quick search, it appears the only
> > > caller for nfs4_listxattr_nfs4_label() is nfs4_listxattr() so I'm
> > > wondering if there isn't some room for improvement here.
> > >
> > > I think there are two obvious options, and I'm curious about your
> > > thoughts on which of these you would prefer, or if there is another
> > > third option that you would like to see merged.
> > >
> > > Option #1:
> > > Essentially back out commit 243fea134633, removing the direct LSM call
> > > in nfs4_listxattr() and relying on the nfs4_listxattr_nfs4_label() for
> > > the LSM/SELinux xattrs. I think we would want to remove the
> > > NFS_CAP_SECURITY_LABEL check and build nfs4_listxattr_nfs4_label()
> > > regardless of CONFIG_NFS_V4_SECURITY_LABEL.
> > >
> > > Option #2:
> > > Remove nfs4_listxattr_nfs4_label() entirely and keep the direct LSM
> > > call in nfs4_listxattr(), with the required changes for this patch.
> > >
> > > Thoughts?
> > >
> > > [1] https://lore.kernel.org/all/20250425180921.86702-1-okorniev@redhat.com/
> >
> > A gentle ping on the question above for the NFS folks. If I don't
> > hear anything I'll hack up something and send it out for review, but I
> > thought it would nice if we could sort out the proper fix first.
>
> Raising this thread back up again to see if the NFS folks have a
> preference on option #1 or #2 above, or
> something else altogether. Should returning of the security.selinux
> xattr name from listxattr() be dependent on
> NFS_CAP_SECURITY_LABEL being set by the server and should it be
> dependent on CONFIG_NFS_V4_SECURITY_LABEL?
Thanks for bringing this back up Stephen, it would be good to get this resolved.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v2] security,fs,nfs,net: update security_inode_listsecurity() interface
From: Stephen Smalley @ 2025-12-03 15:35 UTC (permalink / raw)
To: Paul Moore
Cc: Anna Schumaker, Trond Myklebust, Anna Schumaker, Jakub Kicinski,
Casey Schaufler, Alexander Viro, Christian Brauner, Jan Kara,
James Morris, Serge E. Hallyn, Eric Dumazet, Paolo Abeni,
Willem de Bruijn, David S. Miller, Simon Horman, Ondrej Mosnacek,
linux-nfs, linux-kernel, linux-fsdevel, linux-security-module,
netdev, selinux
In-Reply-To: <CAHC9VhQnR6TKzzzpE9XQqiFivV0ECbVx7GH+1fQmz917-MAhsw@mail.gmail.com>
On Wed, Jul 23, 2025 at 10:10 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Thu, Jun 19, 2025 at 5:18 PM Paul Moore <paul@paul-moore.com> wrote:
> > On Tue, May 27, 2025 at 5:03 PM Anna Schumaker
> > <anna.schumaker@oracle.com> wrote:
> > > On 5/20/25 5:31 PM, Paul Moore wrote:
> > > > On Tue, Apr 29, 2025 at 7:34 PM Paul Moore <paul@paul-moore.com> wrote:
> > > >> On Mon, Apr 28, 2025 at 4:15 PM Stephen Smalley
> > > >> <stephen.smalley.work@gmail.com> wrote:
> > > >>>
> > > >>> Update the security_inode_listsecurity() interface to allow
> > > >>> use of the xattr_list_one() helper and update the hook
> > > >>> implementations.
> > > >>>
> > > >>> Link: https://lore.kernel.org/selinux/20250424152822.2719-1-stephen.smalley.work@gmail.com/
> > > >>>
> > > >>> Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>
> > > >>> ---
> > > >>> This patch is relative to the one linked above, which in theory is on
> > > >>> vfs.fixes but doesn't appear to have been pushed when I looked.
> > > >>>
> > > >>> fs/nfs/nfs4proc.c | 10 ++++++----
> > > >>> fs/xattr.c | 19 +++++++------------
> > > >>> include/linux/lsm_hook_defs.h | 4 ++--
> > > >>> include/linux/security.h | 5 +++--
> > > >>> net/socket.c | 17 +++++++----------
> > > >>> security/security.c | 16 ++++++++--------
> > > >>> security/selinux/hooks.c | 10 +++-------
> > > >>> security/smack/smack_lsm.c | 13 ++++---------
> > > >>> 8 files changed, 40 insertions(+), 54 deletions(-)
> > > >>
> > > >> Thanks Stephen. Once we get ACKs from the NFS, netdev, and Smack
> > > >> folks I can pull this into the LSM tree.
> > > >
> > > > Gentle ping for Trond, Anna, Jakub, and Casey ... can I get some ACKs
> > > > on this patch? It's a little late for the upcoming merge window, but
> > > > I'd like to merge this via the LSM tree after the merge window closes.
> > >
> > > For the NFS change:
> > > Acked-by: Anna Schumaker <anna.schumaker@oracle.com>
> >
> > Hi Anna,
> >
> > Thanks for reviewing the patch. Unfortunately when merging the patch
> > today and fixing up some merge conflicts I bumped into an odd case in
> > the NFS space and I wanted to check with you on how you would like to
> > resolve it.
> >
> > Commit 243fea134633 ("NFSv4.2: fix listxattr to return selinux
> > security label")[1] adds a direct call to
> > security_inode_listsecurity() in nfs4_listxattr(), despite the
> > existing nfs4_listxattr_nfs4_label() call which calls into the same
> > LSM hook, although that call is conditional on the server supporting
> > NFS_CAP_SECURITY_LABEL. Based on a quick search, it appears the only
> > caller for nfs4_listxattr_nfs4_label() is nfs4_listxattr() so I'm
> > wondering if there isn't some room for improvement here.
> >
> > I think there are two obvious options, and I'm curious about your
> > thoughts on which of these you would prefer, or if there is another
> > third option that you would like to see merged.
> >
> > Option #1:
> > Essentially back out commit 243fea134633, removing the direct LSM call
> > in nfs4_listxattr() and relying on the nfs4_listxattr_nfs4_label() for
> > the LSM/SELinux xattrs. I think we would want to remove the
> > NFS_CAP_SECURITY_LABEL check and build nfs4_listxattr_nfs4_label()
> > regardless of CONFIG_NFS_V4_SECURITY_LABEL.
> >
> > Option #2:
> > Remove nfs4_listxattr_nfs4_label() entirely and keep the direct LSM
> > call in nfs4_listxattr(), with the required changes for this patch.
> >
> > Thoughts?
> >
> > [1] https://lore.kernel.org/all/20250425180921.86702-1-okorniev@redhat.com/
>
> A gentle ping on the question above for the NFS folks. If I don't
> hear anything I'll hack up something and send it out for review, but I
> thought it would nice if we could sort out the proper fix first.
Raising this thread back up again to see if the NFS folks have a
preference on option #1 or #2 above, or
something else altogether. Should returning of the security.selinux
xattr name from listxattr() be dependent on
NFS_CAP_SECURITY_LABEL being set by the server and should it be
dependent on CONFIG_NFS_V4_SECURITY_LABEL?
^ permalink raw reply
* Re: [PATCH 00/46] Allow inlining C helpers into Rust when using LTO
From: Gary Guo @ 2025-12-03 14:33 UTC (permalink / raw)
To: Alice Ryhl
Cc: rust-for-linux, linux-kernel, Greg Kroah-Hartman, Dave Ertman,
Ira Weiny, Leon Romanovsky, Peter Zijlstra, Boqun Feng,
Elle Rhumsaa, Carlos Llamas, Yury Norov, Andreas Hindborg,
linux-block, FUJITA Tomonori, Miguel Ojeda, Michael Turquette,
Stephen Boyd, linux-clk, Benno Lossin, Danilo Krummrich,
Thomas Gleixner, Rafael J. Wysocki, Viresh Kumar, linux-pm,
Paul Moore, Serge Hallyn, linux-security-module, Daniel Almeida,
Abdiel Janulgue, Robin Murphy, Lyude Paul, Alexander Viro,
Christian Brauner, Jan Kara, linux-fsdevel, Josh Poimboeuf,
Jason Baron, Steven Rostedt, Ard Biesheuvel, Brendan Higgins,
David Gow, Rae Moar, linux-kselftest, Andrew Morton,
Liam R. Howlett, Andrew Ballance, maple-tree, linux-mm,
Lorenzo Stoakes, Uladzislau Rezki, Vitaly Wool, Rob Herring,
Saravana Kannan, devicetree, Bjorn Helgaas,
Krzysztof Wilczyński, linux-pci, Remo Senekowitsch,
Paul E. McKenney, rcu, Will Deacon, Fiona Behrens, Liam Girdwood,
Mark Brown, Alexandre Courbot, Vlastimil Babka, Christoph Lameter,
David Rientjes, Ingo Molnar, Waiman Long, Mitchell Levy,
Frederic Weisbecker, Anna-Maria Behnsen, John Stultz, linux-usb,
Tejun Heo, Lai Jiangshan, Matthew Wilcox, Tamir Duberstein
In-Reply-To: <20251202-define-rust-helper-v1-0-a2e13cbc17a6@google.com>
On Tue, 02 Dec 2025 19:37:24 +0000
Alice Ryhl <aliceryhl@google.com> wrote:
> This patch series adds __rust_helper to every single rust helper. The
> patches do not depend on each other, so maintainers please go ahead and
> pick up any patches relevant to your subsystem! Or provide your Acked-by
> so that Miguel can pick them up.
>
> These changes were generated by adding __rust_helper and running
> ClangFormat. Unrelated formatting changes were removed manually.
>
> Why is __rust_helper needed?
> ============================
>
> Currently, C helpers cannot be inlined into Rust even when using LTO
> because LLVM detects slightly different options on the codegen units.
>
> * LLVM doesn't want to inline functions compiled with
> `-fno-delete-null-pointer-checks` with code compiled without. The C
> CGUs all have this enabled and Rust CGUs don't. Inlining is okay since
> this is one of the hardening features that does not change the ABI,
> and we shouldn't have null pointer dereferences in these helpers.
>
> * LLVM doesn't want to inline functions with different list of builtins. C
> side has `-fno-builtin-wcslen`; `wcslen` is not a Rust builtin, so
> they should be compatible, but LLVM does not perform inlining due to
> attributes mismatch.
>
> * clang and Rust doesn't have the exact target string. Clang generates
> `+cmov,+cx8,+fxsr` but Rust doesn't enable them (in fact, Rust will
> complain if `-Ctarget-feature=+cmov,+cx8,+fxsr` is used). x86-64
> always enable these features, so they are in fact the same target
> string, but LLVM doesn't understand this and so inlining is inhibited.
> This can be bypassed with `--ignore-tti-inline-compatible`, but this
> is a hidden option.
>
> (This analysis was written by Gary Guo.)
>
> How is this fixed?
> ==================
>
> To fix this we need to add __always_inline to all helpers when compiling
> with LTO. However, it should not be added when running bindgen as
> bindgen will ignore functions marked inline. To achieve this, we are
> using a #define called __rust_helper that is defined differently
> depending on whether bindgen is running or not.
>
> Note that __rust_helper is currently always #defined to nothing.
> Changing it to __always_inline will happen separately in another patch
> series.
>
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
> Alice Ryhl (46):
> rust: auxiliary: add __rust_helper to helpers
> rust: barrier: add __rust_helper to helpers
> rust: binder: add __rust_helper to helpers
> rust: bitmap: add __rust_helper to helpers
> rust: bitops: add __rust_helper to helpers
> rust: blk: add __rust_helper to helpers
> rust: bug: add __rust_helper to helpers
> rust: clk: add __rust_helper to helpers
> rust: completion: add __rust_helper to helpers
> rust: cpu: add __rust_helper to helpers
> rust: cpufreq: add __rust_helper to helpers
> rust: cpumask: add __rust_helper to helpers
> rust: cred: add __rust_helper to helpers
> rust: device: add __rust_helper to helpers
> rust: dma: add __rust_helper to helpers
> rust: drm: add __rust_helper to helpers
> rust: err: add __rust_helper to helpers
> rust: fs: add __rust_helper to helpers
> rust: io: add __rust_helper to helpers
> rust: irq: add __rust_helper to helpers
> rust: jump_label: add __rust_helper to helpers
> rust: kunit: add __rust_helper to helpers
> rust: maple_tree: add __rust_helper to helpers
> rust: mm: add __rust_helper to helpers
> rust: of: add __rust_helper to helpers
> rust: pci: add __rust_helper to helpers
> rust: pid_namespace: add __rust_helper to helpers
> rust: platform: add __rust_helper to helpers
> rust: poll: add __rust_helper to helpers
> rust: processor: add __rust_helper to helpers
> rust: property: add __rust_helper to helpers
> rust: rbtree: add __rust_helper to helpers
> rust: rcu: add __rust_helper to helpers
> rust: refcount: add __rust_helper to helpers
> rust: regulator: add __rust_helper to helpers
> rust: scatterlist: add __rust_helper to helpers
> rust: security: add __rust_helper to helpers
> rust: slab: add __rust_helper to helpers
> rust: sync: add __rust_helper to helpers
> rust: task: add __rust_helper to helpers
> rust: time: add __rust_helper to helpers
> rust: uaccess: add __rust_helper to helpers
> rust: usb: add __rust_helper to helpers
> rust: wait: add __rust_helper to helpers
> rust: workqueue: add __rust_helper to helpers
> rust: xarray: add __rust_helper to helpers
Thansk for sending this Alice! With this series in first, my series for
inlining helpers should be much easier to apply.
For the whole series:
Reviewed-by: Gary Guo <gary@garyguo.net>
Best,
Gary
>
> rust/helpers/auxiliary.c | 6 +++--
> rust/helpers/barrier.c | 6 ++---
> rust/helpers/binder.c | 13 ++++-----
> rust/helpers/bitmap.c | 6 +++--
> rust/helpers/bitops.c | 11 +++++---
> rust/helpers/blk.c | 4 +--
> rust/helpers/bug.c | 4 +--
> rust/helpers/build_bug.c | 2 +-
> rust/helpers/clk.c | 24 +++++++++--------
> rust/helpers/completion.c | 2 +-
> rust/helpers/cpu.c | 2 +-
> rust/helpers/cpufreq.c | 3 ++-
> rust/helpers/cpumask.c | 32 +++++++++++++---------
> rust/helpers/cred.c | 4 +--
> rust/helpers/device.c | 16 +++++------
> rust/helpers/dma.c | 15 ++++++-----
> rust/helpers/drm.c | 7 ++---
> rust/helpers/err.c | 6 ++---
> rust/helpers/fs.c | 2 +-
> rust/helpers/io.c | 64 +++++++++++++++++++++++---------------------
> rust/helpers/irq.c | 6 +++--
> rust/helpers/jump_label.c | 2 +-
> rust/helpers/kunit.c | 2 +-
> rust/helpers/maple_tree.c | 3 ++-
> rust/helpers/mm.c | 20 +++++++-------
> rust/helpers/mutex.c | 13 ++++-----
> rust/helpers/of.c | 2 +-
> rust/helpers/page.c | 9 ++++---
> rust/helpers/pci.c | 13 +++++----
> rust/helpers/pid_namespace.c | 8 +++---
> rust/helpers/platform.c | 2 +-
> rust/helpers/poll.c | 5 ++--
> rust/helpers/processor.c | 2 +-
> rust/helpers/property.c | 2 +-
> rust/helpers/rbtree.c | 5 ++--
> rust/helpers/rcu.c | 4 +--
> rust/helpers/refcount.c | 10 +++----
> rust/helpers/regulator.c | 24 ++++++++++-------
> rust/helpers/scatterlist.c | 12 +++++----
> rust/helpers/security.c | 26 ++++++++++--------
> rust/helpers/signal.c | 2 +-
> rust/helpers/slab.c | 14 +++++-----
> rust/helpers/spinlock.c | 13 ++++-----
> rust/helpers/sync.c | 4 +--
> rust/helpers/task.c | 24 ++++++++---------
> rust/helpers/time.c | 12 ++++-----
> rust/helpers/uaccess.c | 8 +++---
> rust/helpers/usb.c | 3 ++-
> rust/helpers/vmalloc.c | 7 ++---
> rust/helpers/wait.c | 2 +-
> rust/helpers/workqueue.c | 8 +++---
> rust/helpers/xarray.c | 10 +++----
> 52 files changed, 280 insertions(+), 226 deletions(-)
> ---
> base-commit: 54e3eae855629702c566bd2e130d9f40e7f35bde
> change-id: 20251202-define-rust-helper-f7b531813007
>
> Best regards,
^ permalink raw reply
* Re: Are setuid shell scripts safe? (Implied by security_bprm_creds_for_exec)
From: Bernd Edlinger @ 2025-12-03 13:16 UTC (permalink / raw)
To: Eric W. Biederman, Roberto Sassu
Cc: Alexander Viro, Alexey Dobriyan, Oleg Nesterov, Kees Cook,
Andy Lutomirski, Will Drewry, Christian Brauner, Andrew Morton,
Michal Hocko, Serge Hallyn, James Morris, Randy Dunlap,
Suren Baghdasaryan, Yafang Shao, Helge Deller, Adrian Reber,
Thomas Gleixner, Jens Axboe, Alexei Starovoitov,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest, linux-mm, linux-security-module, tiozhang,
Luis Chamberlain, Paulo Alcantara (SUSE), Sergey Senozhatsky,
Frederic Weisbecker, YueHaibing, Paul Moore, Aleksa Sarai,
Stefan Roesch, Chao Yu, xu xin, Jeff Layton, Jan Kara,
David Hildenbrand, Dave Chinner, Shuah Khan, Elena Reshetova,
David Windsor, Mateusz Guzik, Ard Biesheuvel,
Joel Fernandes (Google), Matthew Wilcox (Oracle),
Hans Liljestrand, Penglei Jiang, Lorenzo Stoakes, Adrian Ratiu,
Ingo Molnar, Peter Zijlstra (Intel), Cyrill Gorcunov,
Eric Dumazet, zohar, linux-integrity, Ryan Lee, apparmor
In-Reply-To: <87ms42rq3t.fsf@email.froward.int.ebiederm.org>
On 12/1/25 19:53, Eric W. Biederman wrote:
> Roberto Sassu <roberto.sassu@huaweicloud.com> writes:
>
>> On Mon, 2025-12-01 at 10:06 -0600, Eric W. Biederman wrote:
>>> Roberto Sassu <roberto.sassu@huaweicloud.com> writes:
>>>
>>>> + Mimi, linux-integrity (would be nice if we are in CC when linux-
>>>> security-module is in CC).
>>>>
>>>> Apologies for not answering earlier, it seems I don't receive the
>>>> emails from the linux-security-module mailing list (thanks Serge for
>>>> letting me know!).
>>>>
>>>> I see two main effects of this patch. First, the bprm_check_security
>>>> hook implementations will not see bprm->cred populated. That was a
>>>> problem before we made this patch:
>>>>
>>>> https://patchew.org/linux/20251008113503.2433343-1-roberto.sassu@huaweicloud.com/
>>>
>>> Thanks, that is definitely needed.
>>>
>>> Does calling process_measurement(CREDS_CHECK) on only the final file
>>> pass review? Do you know of any cases where that will break things?
>>
>> We intentionally changed the behavior of CREDS_CHECK to be invoked only
>> for the final file. We are monitoring for bug reports, if we receive
>> complains from people that the patch breaks their expectation we will
>> revisit the issue.
>>
>> Any LSM implementing bprm_check_security looking for brpm->cred would
>> be affected by recalculating the DAC credentials for the final binary.
>>
>>> As it stands I don't think it should be assumed that any LSM has
>>> computed it's final creds until bprm_creds_from_file. Not just the
>>> uid and gid.
>>
>> Uhm, I can be wrong, but most LSMs calculate their state change in
>> bprm_creds_for_exec (git grep bprm_creds_for_exec|grep LSM_HOOK_INIT).
>>
>>> If the patch you posted for review works that helps sort that mess out.
>>
>> Well, it works because we changed the expectation :)
>
> I just haven't seen that code land in Linus's tree yet so I am a bit
> cautious in adopting that. It is definitely needed as the behavior
> of IMA as v6.18 simply does not work in general.
>
>>>> to work around the problem of not calculating the final DAC credentials
>>>> early enough (well, we actually had to change our CREDS_CHECK hook
>>>> behavior).
>>>>
>>>> The second, I could not check. If I remember well, unlike the
>>>> capability LSM, SELinux/Apparmor/SMACK calculate the final credentials
>>>> based on the first file being executed (thus the script, not the
>>>> interpreter). Is this patch keeping the same behavior despite preparing
>>>> the credentials when the final binary is found?
>>>
>>> The patch I posted was.
>>>
>>> My brain is still reeling from the realization that our security modules
>>> have the implicit assumption that it is safe to calculate their security
>>> information from shell scripts.
>>
>> If I'm interpreting this behavior correctly (please any LSM maintainer
>> could comment on it), the intent is just to transition to a different
>> security context where a different set of rules could apply (since we
>> are executing a script).
>>
>> Imagine if for every script, the security transition is based on the
>> interpreter, it would be hard to differentiate between scripts and
>> associate to the respective processes different security labels.
>>
>>> In the first half of the 90's I remember there was lots of effort to try
>>> and make setuid shell scripts and setuid perl scripts work, and the
>>> final conclusion was it was a lost cause.
>>
>> Definitely I lack a lot of context...
>
> From the usenet comp.unix.faq that was probably updated in 1994:
> http://www.faqs.org/faqs/unix-faq/faq/part4/section-7.html
>
> I have been trying to remember enough details by looking it up, but the
> short version is that one of the big problems is there is a race between
> the kernel doing it's thing and the shell opening the shell script.
>
> Clever people have been able to take advantage of that race and insert
> arbitrary code in that window for the shell to execute. All you have to
> do is google for how to find a reproducer if the one in the link above
> is not enough.
>
>>> Now I look at security_bprm_creds_for_exec and security_bprm_check which
>>> both have the implicit assumption that it is indeed safe to compute the
>>> credentials from a shell script.
>>>
>>> When passing a file descriptor to execat we have
>>> BINPRM_FLAGS_PATH_INACCESSIBLE and use /dev/fd/NNN as the filename
>>> which reduces some of the races.
>>>
>>> However when just plain executing a shell script we pass the filename of
>>> the shell script as a command line argument, and expect the shell to
>>> open the filename again. This has been a time of check to time of use
>>> race for decades, and one of the reasons we don't have setuid shell
>>> scripts.
>>
>> Yes, it would be really nice to fix it!
>
> After 30 years I really don't expect that is even a reasonable request.
>
> I think we are solidly into "Don't do that then", and the LSM security
> hooks are definitely doing that.
>
> There is the partial solution of passing /dev/fd instead of passing the
> name of the script. I suspect that would break things. I don't
> remember why that was never adopted.
>
> I think even with the TOCTOU race fixed there were other serious issues.
>
> I really think it behooves any security module people who want to use
> the shell script as the basis of their security decisions to research
> all of the old well known issues and describe how they don't apply.
>
> All I have energy for is to point out it is broken as is and to start
> moving code down into bprm_creds_from_file to avoid the race.
>
> Right now as far as I can tell anything based upon the script itself
> is worthless junk so changing that would not be breaking anything that
> wasn't already broken.
>
>>> Yet the IMA implementation (without the above mentioned patch) assumes
>>> the final creds will be calculated before security_bprm_check is called,
>>> and security_bprm_creds_for_exec busily calculate the final creds.
>>>
>>> For some of the security modules I believe anyone can set any label they
>>> want on a file and they remain secure (At which point I don't understand
>>> the point of having labels on files). I don't believe that is the case
>>> for selinux, or in general.
>>
>> A simple example for SELinux. Suppose that the parent process has type
>> initrc_t, then the SELinux policy configures the following transitions
>> based on the label of the first file executed (sesearch -T -s initrc_t
>> -c process):
>>
>> type_transition initrc_t NetworkManager_dispatcher_exec_t:process NetworkManager_dispatcher_t;
>> type_transition initrc_t NetworkManager_exec_t:process NetworkManager_t;
>> type_transition initrc_t NetworkManager_initrc_exec_t:process initrc_t;
>> type_transition initrc_t NetworkManager_priv_helper_exec_t:process NetworkManager_priv_helper_t;
>> type_transition initrc_t abrt_dump_oops_exec_t:process abrt_dump_oops_t;
>> type_transition initrc_t abrt_exec_t:process abrt_t;
>> [...]
>>
>> (there are 747 rules in my system).
>>
>> If the transition would be based on the interpreter label, it would be
>> hard to express with rules.
>
> Which is a problem for the people making the rules engine. Because
> 30 years of experience with this problem says basing anything on the
> script is already broken.
>
> I understand the frustration, but it requires a new way of launching
> shell scripts to even begin to make it secure.
>
>> If the transition does not occur for any reason the parent process
>> policy would still apply, but maybe it would not have the necessary
>> permissions for the execution of the script.
>
> Yep.
>
>>> So just to remove the TOCTOU race the security_bprm_creds_for_exec
>>> and security_bprm_check hooks need to be removed, after moving their
>>> code into something like security_bprm_creds_from_file.
>>>
>>> Or am I missing something and even with the TOCTOU race are setuid shell
>>> scripts somehow safe now?
>>
>> Take this with a looot of salt, if there is a TOCTOU race, the script
>> will be executed with a security context that does not belong to it.
>> But the transition already happened. Not sure if it is safe.
>
> Historically it hasn't been safe.
>
>> I also don't know how the TOCTOU race could be solved, but I also would
>> like it to be fixed. I'm available to comment on any proposal!
>
> I am hoping someone who helped put these security hooks where they are
> will speak up, and tell me what I am missing.
>
> All I have the energy for right now is to point out security policies
> based upon shell scripts appear to be security policies that only
> protect you from well behaved programs.
>
Hmm, yes, that looks like an issue.
I would have expected the security engine to look at bprm->filenanme
especially in the case, when bprm->interp != bprm->filename,
and check that it is not a sym-link with write-access for the
current user and of course also that the bprm->file is not a regular file
which is writable by the current user, if that is the case I would have expected
the secuity engine to enforce non-new-privs on a SUID executable somehow.
Bernd.
^ permalink raw reply
* Re: [PATCH] selftests/landlock: NULL-terminate unix pathname addresses
From: Günther Noack @ 2025-12-03 9:48 UTC (permalink / raw)
To: Matthieu Buffet; +Cc: Mickaël Salaün, linux-security-module
In-Reply-To: <20251202215141.689986-1-matthieu@buffet.re>
On Tue, Dec 02, 2025 at 10:51:41PM +0100, Matthieu Buffet wrote:
> The size of Unix pathname addresses is computed in selftests using
> offsetof(struct sockaddr_un, sun_path) + strlen(xxx). It should have
> been that +1, which makes addresses passed to the libc and kernel
> non-NULL-terminated. unix_mkname_bsd() fixes that in Linux so there is
> no harm, but just using sizeof(the address struct) should improve
> readability.
>
> Signed-off-by: Matthieu Buffet <matthieu@buffet.re>
> ---
> [...]
Thank you very much, this looks good!
Reviewed-by: Günther Noack <gnoack@google.com>
—Günther
^ permalink raw reply
* [GIT PULL] IPE update for 6.19
From: Fan Wu @ 2025-12-03 4:01 UTC (permalink / raw)
To: torvalds
Cc: linux-security-module, Linux Kernel Mailing List,
Borislav Petkov (AMD), Yanzhu Huang
Hi Linus,
Please merge this PR for the IPE (Integrity Policy Enforcement) update for 6.19.
This PR contains three commits. The primary change is the addition of
support for the AT_EXECVE_CHECK flag. This allows interpreters to
signal the kernel to perform IPE security checks on script files
before execution, extending IPE enforcement to indirectly executed
scripts.
These commits have been tested for several weeks in linux-next without
any issues.
Thanks,
Fan
--
The following changes since commit 7d0a66e4bb9081d75c82ec4957c50034cb0ea449:
Linux 6.18 (2025-11-30 14:42:10 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/wufan/ipe.git
tags/ipe-pr-20251202
for you to fetch changes up to d7ba853c0e47d57805181f5269ba250270d2adde:
ipe: Update documentation for script enforcement (2025-12-02 19:37:10 -0800)
----------------------------------------------------------------
ipe/stable-6.19 PR 20251202
----------------------------------------------------------------
Borislav Petkov (AMD) (1):
ipe: Drop a duplicated CONFIG_ prefix in the ifdeffery
Yanzhu Huang (2):
ipe: Add AT_EXECVE_CHECK support for script enforcement
ipe: Update documentation for script enforcement
Documentation/admin-guide/LSM/ipe.rst | 17 ++++++++++++++---
security/ipe/audit.c | 1 +
security/ipe/hooks.c | 29 ++++++++++++++++++++++++++++-
security/ipe/hooks.h | 3 +++
security/ipe/ipe.c | 1 +
5 files changed, 47 insertions(+), 4 deletions(-)
^ permalink raw reply
* Re: [PATCH 00/46] Allow inlining C helpers into Rust when using LTO
From: Boqun Feng @ 2025-12-03 1:47 UTC (permalink / raw)
To: Alice Ryhl
Cc: rust-for-linux, linux-kernel, Greg Kroah-Hartman, Dave Ertman,
Ira Weiny, Leon Romanovsky, Peter Zijlstra, Elle Rhumsaa,
Carlos Llamas, Yury Norov, Andreas Hindborg, linux-block,
FUJITA Tomonori, Miguel Ojeda, Michael Turquette, Stephen Boyd,
linux-clk, Benno Lossin, Danilo Krummrich, Thomas Gleixner,
Rafael J. Wysocki, Viresh Kumar, linux-pm, Paul Moore,
Serge Hallyn, linux-security-module, Daniel Almeida,
Abdiel Janulgue, Robin Murphy, Lyude Paul, Alexander Viro,
Christian Brauner, Jan Kara, linux-fsdevel, Josh Poimboeuf,
Jason Baron, Steven Rostedt, Ard Biesheuvel, Brendan Higgins,
David Gow, Rae Moar, linux-kselftest, Andrew Morton,
Liam R. Howlett, Andrew Ballance, maple-tree, linux-mm,
Lorenzo Stoakes, Uladzislau Rezki, Vitaly Wool, Rob Herring,
Saravana Kannan, devicetree, Bjorn Helgaas,
Krzysztof Wilczy´nski, linux-pci, Remo Senekowitsch,
Paul E. McKenney, rcu, Will Deacon, Fiona Behrens, Gary Guo,
Liam Girdwood, Mark Brown, Alexandre Courbot, Vlastimil Babka,
Christoph Lameter, David Rientjes, Ingo Molnar, Waiman Long,
Mitchell Levy, Frederic Weisbecker, Anna-Maria Behnsen,
John Stultz, linux-usb, Tejun Heo, Lai Jiangshan, Matthew Wilcox,
Tamir Duberstein
In-Reply-To: <20251202-define-rust-helper-v1-0-a2e13cbc17a6@google.com>
On Tue, Dec 02, 2025 at 07:37:24PM +0000, Alice Ryhl wrote:
> This patch series adds __rust_helper to every single rust helper. The
> patches do not depend on each other, so maintainers please go ahead and
> pick up any patches relevant to your subsystem! Or provide your Acked-by
> so that Miguel can pick them up.
>
> These changes were generated by adding __rust_helper and running
> ClangFormat. Unrelated formatting changes were removed manually.
>
> Why is __rust_helper needed?
> ============================
>
> Currently, C helpers cannot be inlined into Rust even when using LTO
> because LLVM detects slightly different options on the codegen units.
>
> * LLVM doesn't want to inline functions compiled with
> `-fno-delete-null-pointer-checks` with code compiled without. The C
> CGUs all have this enabled and Rust CGUs don't. Inlining is okay since
> this is one of the hardening features that does not change the ABI,
> and we shouldn't have null pointer dereferences in these helpers.
>
> * LLVM doesn't want to inline functions with different list of builtins. C
> side has `-fno-builtin-wcslen`; `wcslen` is not a Rust builtin, so
> they should be compatible, but LLVM does not perform inlining due to
> attributes mismatch.
>
> * clang and Rust doesn't have the exact target string. Clang generates
> `+cmov,+cx8,+fxsr` but Rust doesn't enable them (in fact, Rust will
> complain if `-Ctarget-feature=+cmov,+cx8,+fxsr` is used). x86-64
> always enable these features, so they are in fact the same target
> string, but LLVM doesn't understand this and so inlining is inhibited.
> This can be bypassed with `--ignore-tti-inline-compatible`, but this
> is a hidden option.
>
> (This analysis was written by Gary Guo.)
>
> How is this fixed?
> ==================
>
> To fix this we need to add __always_inline to all helpers when compiling
> with LTO. However, it should not be added when running bindgen as
> bindgen will ignore functions marked inline. To achieve this, we are
> using a #define called __rust_helper that is defined differently
> depending on whether bindgen is running or not.
>
> Note that __rust_helper is currently always #defined to nothing.
> Changing it to __always_inline will happen separately in another patch
> series.
>
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
For the whole series:
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Regards,
Boqun
> ---
[...]
^ permalink raw reply
* [PATCH 1/1] IMA event log trimming
From: steven chen @ 2025-12-02 23:28 UTC (permalink / raw)
To: linux-integrity
Cc: zohar, roberto.sassu, dmitry.kasatkin, eric.snowberg, paul,
jmorris, serge, linux-security-module, anirudhve, chenste,
gregorylumen, nramas, sushring
In-Reply-To: <20251202232857.8211-1-chenste@linux.microsoft.com>
This patch is for trimming N entries of the IMA event logs as well as
cleaning the hash table.
It provides a userspace interface ima_trim_log that can be used to input
number N to let kernel to trim N entries of IMA event logs. When read
this interface, it returns number of entries trimmed last tim.
A mutex ima_trim_list_mutex is provided to allow one trimming request
at a time.
Signed-off-by: steven chen <chenste@linux.microsoft.com>
---
security/integrity/ima/ima.h | 2 +
security/integrity/ima/ima_fs.c | 78 ++++++++++++++++++++++++++++++
security/integrity/ima/ima_queue.c | 42 ++++++++++++++++
3 files changed, 122 insertions(+)
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index e3d71d8d56e3..ab0e30ee25ea 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -246,8 +246,10 @@ void ima_post_key_create_or_update(struct key *keyring, struct key *key,
#ifdef CONFIG_IMA_KEXEC
void ima_measure_kexec_event(const char *event_name);
+long ima_purge_event_log(long number_logs);
#else
static inline void ima_measure_kexec_event(const char *event_name) {}
+static inline long ima_purge_event_log(long number_logs) { return 0; }
#endif
/*
diff --git a/security/integrity/ima/ima_fs.c b/security/integrity/ima/ima_fs.c
index 87045b09f120..ea93448feedd 100644
--- a/security/integrity/ima/ima_fs.c
+++ b/security/integrity/ima/ima_fs.c
@@ -38,6 +38,11 @@ __setup("ima_canonical_fmt", default_canonical_fmt_setup);
static int valid_policy = 1;
+#define IMA_LOG_TRIM_REQ_LENGTH 11
+static long trimcount;
+/* mutex protects atomicity of trimming measurement list requests */
+static DEFINE_MUTEX(ima_trim_list_mutex);
+
static ssize_t ima_show_htable_value(char __user *buf, size_t count,
loff_t *ppos, atomic_long_t *val)
{
@@ -289,6 +294,69 @@ static const struct file_operations ima_ascii_measurements_ops = {
.release = seq_release,
};
+static int ima_log_trim_open(struct inode *inode, struct file *filp)
+{
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+ return 0;
+}
+
+static ssize_t ima_log_trim_read(struct file *file, char __user *buf, size_t size, loff_t *ppos)
+{
+ char tmpbuf[IMA_LOG_TRIM_REQ_LENGTH]; /* greater than largest 'long' string value */
+ ssize_t len;
+
+ len = scnprintf(tmpbuf, sizeof(tmpbuf), "%li\n", trimcount);
+ return simple_read_from_buffer(buf, size, ppos, tmpbuf, len);
+}
+
+static ssize_t ima_log_trim_write(struct file *file,
+ const char __user *buf, size_t datalen, loff_t *ppos)
+{
+ unsigned char req[IMA_LOG_TRIM_REQ_LENGTH];
+ long count, n;
+ int ret;
+
+ mutex_lock(&ima_trim_list_mutex);
+
+ if (*ppos > 0 || datalen > IMA_LOG_TRIM_REQ_LENGTH || datalen < 2) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ n = (int)datalen;
+
+ ret = copy_from_user(req, buf, datalen);
+ if (ret < 0)
+ goto out;
+
+ count = 0;
+ for (int i = 0; i < n; ++i) {
+ if (req[i] < '0' || req[i] > '9') {
+ ret = -EINVAL;
+ goto out;
+ }
+ count = count * 10 + req[i] - '0';
+ }
+ ret = ima_purge_event_log(count);
+
+ if (ret < 0)
+ goto out;
+
+ trimcount = ret;
+ ret = datalen;
+out:
+ mutex_unlock(&ima_trim_list_mutex);
+ return ret;
+}
+
+static const struct file_operations ima_log_trim_ops = {
+ .open = ima_log_trim_open,
+ .read = ima_log_trim_read,
+ .write = ima_log_trim_write,
+ .llseek = generic_file_llseek,
+};
+
static ssize_t ima_read_policy(char *path)
{
void *data = NULL;
@@ -528,6 +596,16 @@ int __init ima_fs_init(void)
goto out;
}
+ dentry = securityfs_create_file("ima_trim_log",
+ S_IRUSR | S_IRGRP | S_IWUSR | S_IWGRP,
+ ima_dir, NULL, &ima_log_trim_ops);
+ if (IS_ERR(dentry)) {
+ ret = PTR_ERR(dentry);
+ goto out;
+ }
+
+ trimcount = 0;
+
dentry = securityfs_create_file("runtime_measurements_count",
S_IRUSR | S_IRGRP, ima_dir, NULL,
&ima_measurements_count_ops);
diff --git a/security/integrity/ima/ima_queue.c b/security/integrity/ima/ima_queue.c
index 590637e81ad1..999cd42c517c 100644
--- a/security/integrity/ima/ima_queue.c
+++ b/security/integrity/ima/ima_queue.c
@@ -220,6 +220,48 @@ int ima_add_template_entry(struct ima_template_entry *entry, int violation,
return result;
}
+/* Delete the IMA event logs */
+long ima_purge_event_log(long number_logs)
+{
+ struct ima_queue_entry *qe;
+ long cur = 0;
+
+ if (number_logs <= 0)
+ return number_logs;
+
+ mutex_lock(&ima_extend_list_mutex);
+ rcu_read_lock();
+
+ /*
+ * Remove this entry from both hash table and the measurement list
+ * When removing from hash table, decrease the length counter
+ * so that the hash table re-sizing logic works correctly
+ */
+ list_for_each_entry_rcu(qe, &ima_measurements, later) {
+ int i;
+
+ /* if CONFIG_IMA_DISABLE_HTABLE is set, the hash table is not used */
+ if (!IS_ENABLED(CONFIG_IMA_DISABLE_HTABLE))
+ hlist_del_rcu(&qe->hnext);
+
+ for (i = 0; i < qe->entry->template_desc->num_fields; i++) {
+ kfree(qe->entry->template_data[i].data);
+ qe->entry->template_data[i].data = NULL;
+ qe->entry->template_data[i].len = 0;
+ }
+
+ atomic_long_dec(&ima_htable.len);
+ list_del_rcu(&qe->later);
+ ++cur;
+ if (cur >= number_logs)
+ break;
+ }
+
+ rcu_read_unlock();
+ mutex_unlock(&ima_extend_list_mutex);
+ return cur;
+}
+
int ima_restore_measurement_entry(struct ima_template_entry *entry)
{
int result = 0;
--
2.43.0
^ permalink raw reply related
* [PATCH 0/1] Trim N entries of IMA event logs
From: steven chen @ 2025-12-02 23:28 UTC (permalink / raw)
To: linux-integrity
Cc: zohar, roberto.sassu, dmitry.kasatkin, eric.snowberg, paul,
jmorris, serge, linux-security-module, anirudhve, chenste,
gregorylumen, nramas, sushring
The Integrity Measurement Architecture (IMA) maintains a measurement list
—a record of system events used for integrity verification. The IMA event
logs are the entries within this measurement list, each representing a
specific event or measurement that contributes to the system's integrity
assessment.
This update introduces the ability to trim, or remove, N entries from the
current measurement list. Trimming involves deleting N entries from the
list and clearing the corresponding entries from the hash table. This
action atomically truncates the measurement list, ensuring that no new
measurements can be added until the operation is complete. Importantly,
only one writer can initiate this trimming process at a time, maintaining
consistency and preventing race conditions.
A userspace interface, ima_trim_log, has been provided for this purpose.
By writing a number N to this interface, userspace can request the kernel
to trim N entries from the IMA event logs. When this interface is read,
it returns the number of entries trimmed during the last operation. This
value is not preserved across kexec soft reboots, as it is not considered
important information.
To maintain a complete record, userspace is responsible for concatenating
and storing the logs before initiating trimming. Userspace can then send
the collected data to remote verifiers for validation. After receiving
confirmation from the remote verifiers, userspace may instruct the kernel
to proceed with trimming the IMA event logs accordingly.
The primary benefit of this solution is the ability to free valuable
kernel memory by delegating the task of reconstructing the full
measurement list from log chunks to userspace. Trust is not required in
userspace for the integrity of the measurement list, as its integrity is
cryptographically protected by the Trusted Platform Module (TPM).
Multiple readers are allowed to access the ima_trim_log interface
concurrently, while only one writer can trigger log trimming at any time.
During trimming, readers do not see the list and cannot access it while
deletion is in progress, ensuring atomicity.
The time required for trimming is minimal, and IMA event logs are briefly
on hold during this process, preventing read or add operations. This short
interruption has no impact on the overall functionality of IMA.
steven chen (1):
IMA event log trimming
security/integrity/ima/ima.h | 2 +
security/integrity/ima/ima_fs.c | 78 ++++++++++++++++++++++++++++++
security/integrity/ima/ima_queue.c | 42 ++++++++++++++++
3 files changed, 122 insertions(+)
--
2.43.0
^ 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