Refactor audit_log_task_context(), creating a new audit_log_subj_ctx().
This is used in netlabel auditing to provide multiple subject security
contexts as necessary.
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
---
include/linux/audit.h | 7 +++++++
kernel/audit.c | 28 +++++++++++++++++++++-------
net/netlabel/netlabel_user.c | 9 +--------
3 files changed, 29 insertions(+), 15 deletions(-)
diff --git a/include/linux/audit.h b/include/linux/audit.h
index b493ca5976cf..3402e3ca43c6 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -38,6 +38,7 @@ struct audit_tree;
struct sk_buff;
struct kern_ipc_perm;
struct lsm_id;
+struct lsm_prop;
struct audit_krule {
u32 pflags;
@@ -186,6 +187,7 @@ extern void audit_log_path_denied(int type,
const char *operation);
extern void audit_log_lost(const char *message);
+extern int audit_log_subj_ctx(struct audit_buffer *ab, struct lsm_prop *prop);
extern int audit_log_task_context(struct audit_buffer *ab);
extern void audit_log_task_info(struct audit_buffer *ab);
@@ -248,6 +250,11 @@ static inline void audit_log_key(struct audit_buffer *ab, char *key)
{ }
static inline void audit_log_path_denied(int type, const char *operation)
{ }
+static inline int audit_log_subj_ctx(struct audit_buffer *ab,
+ struct lsm_prop *prop)
+{
+ return 0;
+}
static inline int audit_log_task_context(struct audit_buffer *ab)
{
return 0;
diff --git a/kernel/audit.c b/kernel/audit.c
index 7ec3919ae925..8ce453f6dc7d 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -2255,20 +2255,25 @@ static void audit_buffer_aux_end(struct audit_buffer *ab)
ab->skb = skb_peek(&ab->skb_list);
}
-int audit_log_task_context(struct audit_buffer *ab)
+/**
+ * audit_log_subj_ctx - Add LSM subject information
+ * @ab: audit_buffer
+ * @prop: LSM subject properties.
+ *
+ * Add a subj= field and, if necessary, a AUDIT_MAC_TASK_CONTEXTS record.
+ */
+int audit_log_subj_ctx(struct audit_buffer *ab, struct lsm_prop *prop)
{
- struct lsm_prop prop;
struct lsm_context ctx;
bool space = false;
int error;
int i;
- security_current_getlsmprop_subj(&prop);
- if (!lsmprop_is_set(&prop))
+ if (!lsmprop_is_set(prop))
return 0;
if (audit_secctx_cnt < 2) {
- error = security_lsmprop_to_secctx(&prop, &ctx, LSM_ID_UNDEF);
+ error = security_lsmprop_to_secctx(prop, &ctx, LSM_ID_UNDEF);
if (error < 0) {
if (error != -EINVAL)
goto error_path;
@@ -2285,7 +2290,7 @@ int audit_log_task_context(struct audit_buffer *ab)
goto error_path;
for (i = 0; i < audit_secctx_cnt; i++) {
- error = security_lsmprop_to_secctx(&prop, &ctx,
+ error = security_lsmprop_to_secctx(prop, &ctx,
audit_lsms[i]->id);
if (error < 0) {
if (error == -EOPNOTSUPP)
@@ -2305,9 +2310,18 @@ int audit_log_task_context(struct audit_buffer *ab)
return 0;
error_path:
- audit_panic("error in audit_log_task_context");
+ audit_panic("error in audit_log_subj_ctx");
return error;
}
+EXPORT_SYMBOL(audit_log_subj_ctx);
+
+int audit_log_task_context(struct audit_buffer *ab)
+{
+ struct lsm_prop prop;
+
+ security_current_getlsmprop_subj(&prop);
+ return audit_log_subj_ctx(ab, &prop);
+}
EXPORT_SYMBOL(audit_log_task_context);
void audit_log_d_path_exe(struct audit_buffer *ab,
diff --git a/net/netlabel/netlabel_user.c b/net/netlabel/netlabel_user.c
index 6d6545297ee3..0da652844dd6 100644
--- a/net/netlabel/netlabel_user.c
+++ b/net/netlabel/netlabel_user.c
@@ -84,7 +84,6 @@ struct audit_buffer *netlbl_audit_start_common(int type,
struct netlbl_audit *audit_info)
{
struct audit_buffer *audit_buf;
- struct lsm_context ctx;
if (audit_enabled == AUDIT_OFF)
return NULL;
@@ -96,13 +95,7 @@ struct audit_buffer *netlbl_audit_start_common(int type,
audit_log_format(audit_buf, "netlabel: auid=%u ses=%u",
from_kuid(&init_user_ns, audit_info->loginuid),
audit_info->sessionid);
-
- if (lsmprop_is_set(&audit_info->prop) &&
- security_lsmprop_to_secctx(&audit_info->prop, &ctx,
- LSM_ID_UNDEF) > 0) {
- audit_log_format(audit_buf, " subj=%s", ctx.context);
- security_release_secctx(&ctx);
- }
+ audit_log_subj_ctx(audit_buf, &audit_info->prop);
return audit_buf;
}
--
2.47.0On Mar 19, 2025 Casey Schaufler <casey@schaufler-ca.com> wrote: > > Refactor audit_log_task_context(), creating a new audit_log_subj_ctx(). > This is used in netlabel auditing to provide multiple subject security > contexts as necessary. > > Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> > --- > include/linux/audit.h | 7 +++++++ > kernel/audit.c | 28 +++++++++++++++++++++------- > net/netlabel/netlabel_user.c | 9 +-------- > 3 files changed, 29 insertions(+), 15 deletions(-) Other than moving to the subject count supplied by the LSM initialization patchset previously mentioned, this looks fine to me. -- paul-moore.com
On 4/24/2025 3:18 PM, Paul Moore wrote: > On Mar 19, 2025 Casey Schaufler <casey@schaufler-ca.com> wrote: >> Refactor audit_log_task_context(), creating a new audit_log_subj_ctx(). >> This is used in netlabel auditing to provide multiple subject security >> contexts as necessary. >> >> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> >> --- >> include/linux/audit.h | 7 +++++++ >> kernel/audit.c | 28 +++++++++++++++++++++------- >> net/netlabel/netlabel_user.c | 9 +-------- >> 3 files changed, 29 insertions(+), 15 deletions(-) > Other than moving to the subject count supplied by the LSM > initialization patchset previously mentioned, this looks fine to me. I'm perfectly willing to switch once the LSM initialization patch set moves past RFC. > > -- > paul-moore.com >
On Wed, Apr 30, 2025 at 12:25 PM Casey Schaufler <casey@schaufler-ca.com> wrote: > On 4/24/2025 3:18 PM, Paul Moore wrote: > > On Mar 19, 2025 Casey Schaufler <casey@schaufler-ca.com> wrote: > >> Refactor audit_log_task_context(), creating a new audit_log_subj_ctx(). > >> This is used in netlabel auditing to provide multiple subject security > >> contexts as necessary. > >> > >> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> > >> --- > >> include/linux/audit.h | 7 +++++++ > >> kernel/audit.c | 28 +++++++++++++++++++++------- > >> net/netlabel/netlabel_user.c | 9 +-------- > >> 3 files changed, 29 insertions(+), 15 deletions(-) > > Other than moving to the subject count supplied by the LSM > > initialization patchset previously mentioned, this looks fine to me. > > I'm perfectly willing to switch once the LSM initialization patch set > moves past RFC. It's obviously your choice as to if/when you switch, but I'm trying to let you know that acceptance into the LSM tree is going to be dependent on that switch happening. The initialization patchset is still very much alive, and the next revision will not be an RFC. I'm simply waiting on some additional LSM specific reviews before posting the next revision so as to not burn out people from looking at multiple iterations. I've been told privately by at least one LSM maintainer that reviewing the changes in their code is on their todo list, but they have been slammed with other work at their job and haven't had the time to look at that patchset yet. I realize you don't have those issues anymore, but I suspect you are still sympathetic to those problems. If you're really anxious to continue work on this RIGHT NOW, you can simply base your patchset on top of the initialization patchset. Just make sure you mention in the cover letter what you are using as a base for the patchset. If that still doesn't offer any satisfaction, you can always incorporate the feedback that I made in v2 that was ignored in your v3 posting :-P -- paul-moore.com
On 4/30/2025 11:51 AM, Paul Moore wrote: > On Wed, Apr 30, 2025 at 12:25 PM Casey Schaufler <casey@schaufler-ca.com> wrote: >> On 4/24/2025 3:18 PM, Paul Moore wrote: >>> On Mar 19, 2025 Casey Schaufler <casey@schaufler-ca.com> wrote: >>>> Refactor audit_log_task_context(), creating a new audit_log_subj_ctx(). >>>> This is used in netlabel auditing to provide multiple subject security >>>> contexts as necessary. >>>> >>>> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> >>>> --- >>>> include/linux/audit.h | 7 +++++++ >>>> kernel/audit.c | 28 +++++++++++++++++++++------- >>>> net/netlabel/netlabel_user.c | 9 +-------- >>>> 3 files changed, 29 insertions(+), 15 deletions(-) >>> Other than moving to the subject count supplied by the LSM >>> initialization patchset previously mentioned, this looks fine to me. >> I'm perfectly willing to switch once the LSM initialization patch set >> moves past RFC. > It's obviously your choice as to if/when you switch, but I'm trying to > let you know that acceptance into the LSM tree is going to be > dependent on that switch happening. Not a problem. Obviously, I'd prefer this patch going in before the LSM initialization work, but it is your call. > The initialization patchset is still very much alive, and the next > revision will not be an RFC. I'm simply waiting on some additional > LSM specific reviews before posting the next revision so as to not > burn out people from looking at multiple iterations. I've been told > privately by at least one LSM maintainer that reviewing the changes in > their code is on their todo list, but they have been slammed with > other work at their job and haven't had the time to look at that > patchset yet. I realize you don't have those issues anymore, but I > suspect you are still sympathetic to those problems. Of course. Waiting on reviews can be frustrating. > If you're really anxious to continue work on this RIGHT NOW, you can > simply base your patchset on top of the initialization patchset. Just > make sure you mention in the cover letter what you are using as a base > for the patchset. As I don't anticipate serious changes to your patch set this makes sense. > If that still doesn't offer any satisfaction, you can always > incorporate the feedback that I made in v2 that was ignored in your v3 > posting :-P Yeah, oops on that.
© 2016 - 2025 Red Hat, Inc.