[PATCH ghak59 V3 2/4] audit: add syscall information to CONFIG_CHANGE records

[Richard Guy Briggs]

On 2019-01-17 08:21, Paul Moore wrote:
> On Thu, Jan 17, 2019 at 4:33 AM Steve Grubb <sgrubb at redhat.com> wrote:
> > On Mon, 14 Jan 2019 17:58:58 -0500 Paul Moore <paul at paul-moore.com> wrote:
> > > On Mon, Dec 10, 2018 at 5:18 PM Richard Guy Briggs <rgb at 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; 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.  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.
> 
> 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.

I would do the change, which should be very trivial, but I'm dense
enough that I still don't know what you want.  In the last 6 months I've
asked a number of direct questions that have not been directly
addressed.  Perhaps I should be able to figure it out from the more
general or fundamental principles replies I've gotten (which have been
helpful, but perhaps incomplete), but I'm still having some trouble.
Perhaps I'm exposing my limitations.

I am understanding mixed messages.

On the one hand, you have said you dislike single-user functions, which
is what the audit_log_user_recv_msg() function is (We had an ongoing
argument about it for audit_set_contid()).  Meanwhile, the
audit_log_config_change_alt() function is used in four places and
simplifies the call by hiding the audit_context() call and the
AUDIT_CONFIG_CHANGE message type.  It would revert to its original form
of audit_log_common_recv_msg(&ab, type) but prefixing audit_context()
from what I am understanding from your comments and I don't really
understand how that is better.  If I go with the latter, I might as well
just call audit_log_common_recv_msg() directly with a NULL context
parameter for AUDIT_*USER* records too.  What am I missing?

If I might attempt another go at humour to convey my perplexion (is that
even a word?) I feel like I'm playing Calvin-ball, but I'm not Calvin.

I don't think I'm being a troll, and hope I'm more technically competent
than I currently feel.

> paul moore

- RGB

--
Richard Guy Briggs <rgb at redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635