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

Paul Moore paul at paul-moore.com
Tue Mar 10 21:42:47 UTC 2020


On Mon, Mar 9, 2020 at 7:01 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
> 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.

I'm open to other suggestions, although I'm struggling to think of
options that don't massively break compat with older userspace.

-- 
paul moore
www.paul-moore.com





More information about the Linux-audit mailing list