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

[Paul Moore]

On Mon, Oct 16, 2017 at 6:28 PM, Steve Grubb <sgrubb at redhat.com> 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?

I've always found the significance placed on auxiliary vs standalone
events amusing.  The only significant difference between the two is
that "auxiliary" records share a timestamp with the other records that
have been triggered by a given syscall instance whereas standlone
records always have a new timestamp generated.  I'm personally of the
opinion that if we are emitting records we should always try to group
related records into a single event to help reduce the confusion for
people looking through their audit logs; in other words, whenever
possible we should pass the audit_context to audit_log_start() and
friends.

If syscall auditing is disabled, these records (e.g.
AUDIT_EVENT_LISTENER) will still be emitted by the kernel as
"standalone" events.  If syscall auditing is enabled, these records
will be grouped with the triggering syscall, which just makes sense.
Look at the recent problem with init/systemd and the MAC_STATUS
records, that is a great example.

-- 
paul moore
www.paul-moore.com