[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2006844.2enhIMKrvE@x2>
Date: Tue, 09 Jun 2020 13:35:14 -0400
From: Steve Grubb <sgrubb@...hat.com>
To: Richard Guy Briggs <rgb@...hat.com>
Cc: Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>,
linux-integrity@...r.kernel.org, linux-audit@...hat.com,
zohar@...ux.ibm.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] IMA: Add audit log for failure conditions
On Tuesday, June 9, 2020 1:15:55 PM EDT Richard Guy Briggs wrote:
> On 2020-06-09 10:00, Lakshmi Ramasubramanian wrote:
> > On 6/9/20 9:43 AM, Steve Grubb wrote:
> > > > The number in parenthesis is the error code (such as ENOMEM, EINVAL,
> > > > etc.) IMA uses this format for reporting TPM errors in one of the
> > > > audit
> > > > messages (In ima_add_template_entry()). I followed the same pattern.
> > > >
> > > > Would it be better if the value for "cause" is formatted as
> > > >
> > > > cause=hashing_error_-22
> > > >
> > > > cause=alloc_entry_-12
> > >
> > > Neither fit the name=value style that all other events follow. What
> > > would fit the style is something like this:
> > >
> > > cause=hashing_error errno=-22
> > > cause=alloc_entry errno=-12
> > >
> > > Would this be OK? Also, errno is only to illustrate. You can name it
> > > something else as long as there are no use case collisions with our
> > > dictionary of field names.
> > >
> > > https://github.com/linux-audit/audit-documentation/blob/master/specs/fi
> > > elds/ field-dictionary.csv
> >
> > I am fine with this.
Thanks, this makes interpreting it a couple lines of code.
> > "errno" is currently not listed in the dictionary of audit message field
> > names (Thanks for the pointer to this one Steve)
It can be easily added.
> > Mimi - please let me know if you have any concerns with adding the
> > "result" code in "errno" field in integrity_audit_msg().
>
> If it is added, it should be appended to the end of the record since it
> is an existing record format, then in the case of res=1, errno= should
> still be present (not swing in and out) and just contain zero. (Or
> another value if there is a non-fatal warning?)
This is not a searchable field, so it can go anywhere. If it is searchable,
ausearch expects ordering of other searchable fields.
-Steve
Powered by blists - more mailing lists