Re: [PATCH ghak59 V3 2/4] audit: add syscall information to CONFIG_CHANGE records
On Thu, 17 Jan 2019 08:21:40 -0500
Paul Moore <paul(a)paul-moore.com> wrote:
On Thu, Jan 17, 2019 at 4:33 AM Steve Grubb <sgrubb(a)redhat.com>
wrote:
> On Mon, 14 Jan 2019 17:58:58 -0500
> Paul Moore <paul(a)paul-moore.com> wrote:
>
> > On Mon, Dec 10, 2018 at 5:18 PM Richard Guy Briggs
> > <rgb(a)redhat.com> wrote:
> > >
> > > Tie syscall information to all CONFIG_CHANGE calls since they
> > > are all a result of user actions.
>
> Please don't tie syscall information to this. The syscall will be
> sendto. We don't need that information, its implicit. Also, doing
> this will possibly wreck things in libauparse. Please test the
> events with ausearch --format csv and --format text. IFF the event
> looks better or the same should we do this. If stuff disappears,
> the patch is breaking things
We've discussed this quite a bit already;
Yes, and you still don't seem be listening. You have to cooperate on
modifying events. We as a community need to respect each other's needs
and work together to solve problems. What this is saying sounds a lot
like I don't care if it breaks things, I'm gonna do it my way. Tough
luck.
You do not have to make sense of any of these events. So, what does it
really matter to you how the event is formed? What I'm asking for is
have these changes been vetted to ensure that they are not breaking
things?
connecting associated records into a single event is something that
should happen, needs to happen, and will happen. Conceptually it
makes no sense to record the syscall (and any other associated
records) which triggers the audit configuration change, and the
configuration change record itself as two distinct events - they are
the same event.
Except that they are not. The design of the audit system is to save
disk space as much as possible by emitting single record events on
certain event types that are simple. To add a syscall to it adds useless
information (such as a socket address record), slows down processing,
and wastes disk space. If you get a SYSCALL record, that indicates that
you have triggered an event that the system admin has placed explicit
rules on. That is different than the common criteria required
configuration change event.
We've also heard from a prominent user that
associating records in this way is desirable.
If the ausearch csv and text audit log transformations can't handle
this particular change, I would consider that a shortcoming of that
code. We have multi-record events now, and this is only going to
increase in the future.
Isn't there some kind a guideline about not breaking user space?
-Steve
Richard, if you can't make the requested changes to this patch
and
resubmit by ... let's say the middle of next week? that should be
enough time, yes? ... please let me know and I'll make the changes and
get this merged.