[PATCH v15 21/23] Audit: Include object data for all security modules

[Casey Schaufler]

On 3/9/2020 10:59 AM, Paul Moore wrote:
> On Mon, Mar 9, 2020 at 1:45 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
>> On 3/6/2020 6:31 PM, Paul Moore wrote:
>>> Either way, the "obj=" field should stay where it is, but the
>>> "obj_XXX=" fields need to find their way to the end of the record.
>> As Steve pointed out, there may be a bigger issue here. If the additional
>> fields aren't going to fit in MAX_AUDIT_MESSAGE_LENGTH bytes another
>> format may be required. I had hoped that perhaps obj_selinux= might count
>> as a refinement to obj= and hence not be considered a new field, but
>> it looks like that's not flying.
> Regardless, the field placement guidance remains the same.

I hear that clearly. End of record.


> As far as the record limitation; yes, Steve's audit userspace does
> have a limit, but I do wonder how limiting an 8k record size really is
> for the majority of systems.  My guess is "not too bad".

Two large path names would be the only worrisome case.
It seems that adding multiple labels will rarely be an issue in
practice, but if we can avoid the difference between theory and
practice we'll be ahead.

> If you are
> concerned about that, I imagine you could always tack on a new record
> to relevant events with additional LSM subj/obj info.

This seems safest, if doing so would be allowed.

>   Some of the
> audit container ID pre-work have made that less painful than it would
> have been in the past, but it will still be a bit of work to get it
> right.

I'd rather put the work in up front than try to fight over whether
records potentially getting too big violates the "don't break user-space"
rules.