[PATCH 1/1] audit: add missing fields to AUDIT_CONFIG_CHANGE event

Paul Moore paul at paul-moore.com
Tue Oct 17 15:17:09 UTC 2017


On Mon, Oct 16, 2017 at 5:17 PM, Steve Grubb <sgrubb at redhat.com> wrote:
> On Monday, October 16, 2017 11:27:06 AM EDT Richard Guy Briggs wrote:
>> On 2017-10-13 21:11, Paul Moore wrote:
>> > On Fri, Oct 13, 2017 at 3:54 PM, Richard Guy Briggs <rgb at redhat.com>
> wrote:
>> > > Since these are already standalone records (since the context passed to
>> > > audit_log_start() is NULL) this info is necessary.
>> >
>> > For the record, I don't have a problem with converting standalone
>> > records to syscall accompanied records if that makes sense (not all
>> > audit events can be attributed to a syscall).
>>
>> I don't either.  I think I've fixed a couple like that in the past when
>> I thought it made sense.
>
> My main objection to this is on wasting disk space and hurting search
> performance. We don't need group information or extended uid information or
> the actual syscall because it will always be a write nor do we need the arch
> or arguments. It also eats more memory when parsing and we have lots of extra
> fields that now need strtok to iterate over.
>
> I'd almost rather add a task record because its more conservative, but syscall
> is the only kind of event that carries auxiliary records. We'd have to
> probably create something to do that if we did go that way. But it sounds like
> more trouble than just adding a couple required fields.

See my comments from today in the multicast/bind patch thread; my
preference is to associate this with an existing audit event.  If that
isn't possible, or desirable from your perspective, then we should add
the new fields at the end.  As far as I'm concerned, at this
particular moment those are the only options that I would be willing
to merge into the kernel.

-- 
paul moore
www.paul-moore.com




More information about the Linux-audit mailing list