[PATCH v32 24/28] Audit: Add framework for auxiliary records

[Casey Schaufler]

On 3/3/2022 2:43 PM, Paul Moore wrote:
> On Thu, Mar 3, 2022 at 5:33 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
>> On 3/3/2022 2:27 PM, Paul Moore wrote:
>>> On Wed, Mar 2, 2022 at 5:32 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
>>>> On 2/2/2022 3:53 PM, Casey Schaufler wrote:
>>>>> Add a list for auxiliary record data to the audit_buffer structure.
>>>>> Add the audit_stamp information to the audit_buffer as there's no
>>>>> guarantee that there will be an audit_context containing the stamp
>>>>> associated with the event. At audit_log_end() time create auxiliary
>>>>> records (none are currently defined) as have been added to the list.
>>>>>
>>>>> Signed-off-by: Casey Schaufler <casey at schaufler-ca.com>
>>>> I'm really hoping for either Acks or feedback on this approach.
>>> The only callers that make use of this functionality in this patchset
>>> is in kernel/audit*.c in patches 25/28 and 26/28, yes?
>> Yes.
> Thanks.  I just wanted to make sure you weren't planning on any
> additional callers in a future revision.  I understand that things may
> change, but I just wanted to make sure there wasn't already something
> pending.

I don't have anything I know about. It's possible that something
could be needed when the stacking changes for networking come in,
but that's not going to come in for "some time" yet.

>> I think that the container ID record could use it as well.
>> I haven't looked deeply, but it should be usable for any aux record type.
> Possibly, but I'm intentionally trying to keep that separated at this
> stage as the ordering is uncertain.  If/when both bits of
> functionality land we can reconcile things as needed; it's all
> internal implementation details so we don't have to worry too much
> about changing it later.

Agreed, although I'd hate to duplicate mechanism if someone else
has an equally functional proposal.