On 2019-01-17 08:21, Paul Moore wrote: > On Thu, Jan 17, 2019 at 4:33 AM Steve Grubb <[email protected]> wrote: > > On Mon, 14 Jan 2019 17:58:58 -0500 Paul Moore <[email protected]> wrote: > > > On Mon, Dec 10, 2018 at 5:18 PM Richard Guy Briggs <[email protected]> > > > 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 <[email protected]> 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 -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
