Re: [PATCH 1/1] audit: log binding and unbinding to netlink multicast

[Steve Grubb <sgrubb@redhat.com>]

On Monday, October 16, 2017 7:04:14 PM EDT Richard Guy Briggs wrote:
> On 2017-10-16 22:28, Steve Grubb wrote:
> > On Monday, October 16, 2017 6:06:47 PM EDT Steve Grubb wrote:
> > > > > +/* Log information about who is connecting to the audit multicast
> > > > > socket
> > > > > */ +static void audit_log_multicast_bind(int group, const char *op,
> > > > > int
> > > > > err) +{
> > > > > +       const struct cred *cred;
> > > > > +       struct tty_struct *tty;
> > > > > +       char comm[sizeof(current->comm)];
> > > > > +       struct audit_buffer *ab;
> > > > > +
> > > > > +       ab = audit_log_start(NULL, GFP_KERNEL,
> > > > > AUDIT_EVENT_LISTENER);
> > > > 
> > > > It really seems like this should be associated with the current task,
> > > > e.g. "audit_log_start(current->audit_context, ...)".  After all, the
> > > > whole point of this record is to capture information about the subject
> > > > who is binding to the multicast socket.
> > > 
> > > OK, easy enough.
> > 
> > But wouldn't that make it an auxiliary record (if there happens to be a
> > syscall record) instead of a standalone event? The intention is that this
> > event is standalone just like AUDIT_SECCOMP or AUDIT_LOGIN. Associating
> > with the current task is done by using current in formatting the message
> > as seen below. (e.g.  task_pid_nr(current), audit_get_sessionid(current))
> > 
> > I think it's correct as is.
> 
> Yes, this would associate this record with the tentatively generated
> SYSCALL record for this task.

OK, then my secondary assessment was right. The patch in this hunk is fine. 
This is a standalone event. I have a patch ready with the .bind/.unbind 
function pointers grouped together. I can add the ghak issue easily enough. I 
just need a ruling on what define number to use for AUDIT_EVENT_LISTENER. 
Should it be 1331 or 1332 (which is its actual number)?

-Steve