[PATCH] lsm_audit: avoid overloading the "key" audit field

The "key" field is used to associate records with the rule that
triggered them, os it's not a good idea to overload it with an
additional IPC key semantic. Moreover, as the classic "key" field is a
text field, while the IPC key is numeric, AVC records containing the IPC
key info actually confuse audit userspace, which tries to interpret the
number as a hex-encoded string, thus showing garbage for example in the
ausearch "interpret" output mode.

Hence, change it to "ipc_key" to fix both issues and also make the
meaning of this field more clear.

Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
---
 security/lsm_audit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/lsm_audit.c b/security/lsm_audit.c
index 5a5016ef43b0..1897cbf6fc69 100644
--- a/security/lsm_audit.c
+++ b/security/lsm_audit.c

@@ -224,7 +224,7 @@ static void dump_common_audit_data(struct audit_buffer *ab,
 	case LSM_AUDIT_DATA_NONE:
 		return;
 	case LSM_AUDIT_DATA_IPC:
-		audit_log_format(ab, " key=%d ", a->u.ipc_id);
+		audit_log_format(ab, " ipc_key=%d ", a->u.ipc_id);
 		break;
 	case LSM_AUDIT_DATA_CAP:
 		audit_log_format(ab, " capability=%d ", a->u.cap);

-- 
2.31.1

On Tue, Sep 14, 2021 at 9:15 AM Ondrej Mosnacek [off-list ref] wrote:

The "key" field is used to associate records with the rule that
triggered them, os it's not a good idea to overload it with an
additional IPC key semantic. Moreover, as the classic "key" field is a
text field, while the IPC key is numeric, AVC records containing the IPC
key info actually confuse audit userspace, which tries to interpret the
number as a hex-encoded string, thus showing garbage for example in the
ausearch "interpret" output mode.

Hence, change it to "ipc_key" to fix both issues and also make the
meaning of this field more clear.

Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
---
 security/lsm_audit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Seems reasonable to me, I can merge it via the audit/next tree unless
James would prefer to take it via the LSM tree.

-- 
paul moore
www.paul-moore.com

On 2021-09-14 15:15, Ondrej Mosnacek wrote:

The "key" field is used to associate records with the rule that
triggered them, os it's not a good idea to overload it with an
additional IPC key semantic. Moreover, as the classic "key" field is a
text field, while the IPC key is numeric, AVC records containing the IPC
key info actually confuse audit userspace, which tries to interpret the
number as a hex-encoded string, thus showing garbage for example in the
ausearch "interpret" output mode.

Hence, change it to "ipc_key" to fix both issues and also make the
meaning of this field more clear.

Good call.

Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>

Reviewed-by: Richard Guy Briggs <redacted>

- RGB

--
Richard Guy Briggs [off-list ref]
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635

On Tue, Sep 14, 2021 at 10:49 AM Paul Moore [off-list ref] wrote:

On Tue, Sep 14, 2021 at 9:15 AM Ondrej Mosnacek [off-list ref] wrote:

quoted

The "key" field is used to associate records with the rule that
triggered them, os it's not a good idea to overload it with an
additional IPC key semantic. Moreover, as the classic "key" field is a
text field, while the IPC key is numeric, AVC records containing the IPC
key info actually confuse audit userspace, which tries to interpret the
number as a hex-encoded string, thus showing garbage for example in the
ausearch "interpret" output mode.

Hence, change it to "ipc_key" to fix both issues and also make the
meaning of this field more clear.

Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
---
 security/lsm_audit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Seems reasonable to me, I can merge it via the audit/next tree unless
James would prefer to take it via the LSM tree.

As this is pretty minor and unlikely to conflict with any LSMs, I've
gone ahead and merged this into the audit/next tree.

-- 
paul moore
www.paul-moore.com