| Message ID | 20210914131516.128823-1-omosnace@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | lsm_audit: avoid overloading the "key" audit field | expand |
On Tue, Sep 14, 2021 at 9:15 AM Ondrej Mosnacek <omosnace@redhat.com> 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. > 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 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 <rgb@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 > - RGB -- Richard Guy Briggs <rgb@redhat.com> 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 <paul@paul-moore.com> wrote: > > On Tue, Sep 14, 2021 at 9:15 AM Ondrej Mosnacek <omosnace@redhat.com> 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. As this is pretty minor and unlikely to conflict with any LSMs, I've gone ahead and merged this into the audit/next tree.
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);
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(-)