Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket

On 14/10/21, Steve Grubb wrote: > On Tuesday, October 07, 2014 03:03:14 PM Eric Paris wrote: > > On Tue, 2014-10-07 at 14:23 -0400, Richard Guy Briggs wrote: > > > Log the event when a client attempts to connect to the netlink audit > > > multicast socket, requiring CAP_AUDIT_READ capability, binding to the > > > AUDIT_NLGRP_READLOG group. Log the disconnect too. > > > > > > > > > > > > Sample output: > > > time->Tue Oct 7 14:15:19 2014 > > > type=UNKNOWN[1348] msg=audit(1412705719.316:117): auid=0 uid=0 gid=0 ses=1 > > > pid=3552 comm="audit-multicast" > > > exe="/home/rgb/rgb/git/audit-multicast-listen/audit-multicast-listen" > > > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 group=0 > > > op=connect res=1> > > > > > > > > > Signed-off-by: Richard Guy Briggs <rgb(a)redhat.com&gt; > > > --- > > > For some reason unbind isn't being called on disconnect. I suspect > > > missing > > > plumbing in netlink. Investigation needed... > > > > > > > > > include/uapi/linux/audit.h | 1 + > > > kernel/audit.c | 46 > > >++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 45 > > >insertions(+), 2 deletions(-) > > > > > > > > > diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h > > > index 4d100c8..7fa6e8f 100644 > > > --- a/include/uapi/linux/audit.h > > > +++ b/include/uapi/linux/audit.h > > > @@ -110,6 +110,7 @@ > > > > > > #define AUDIT_SECCOMP 1326 /* Secure Computing event */ > > > #define AUDIT_PROCTITLE 1327 /* Proctitle emit event */ > > > #define AUDIT_FEATURE_CHANGE 1328 /* audit log listing feature changes > > >*/> > > > +#define AUDIT_EVENT_LISTENER 1348 /* task joined multicast read socket > > > */> > > > > > > #define AUDIT_AVC 1400 /* SE Linux avc denial or grant */ > > > #define AUDIT_SELINUX_ERR 1401 /* Internal SE Linux Errors */ > > > > > > diff --git a/kernel/audit.c b/kernel/audit.c > > > index 53bb39b..74c81a7 100644 > > > --- a/kernel/audit.c > > > +++ b/kernel/audit.c > > > @@ -1108,13 +1108,54 @@ static void audit_receive(struct sk_buff *skb) > > > > > > mutex_unlock(&audit_cmd_mutex); > > > } > > > > > > > > > +static void audit_log_bind(int group, char *op, int err) > > > +{ > > > + struct audit_buffer *ab; > > > + char comm[sizeof(current->comm)]; > > > + struct mm_struct *mm = current->mm; > > > + > > > + ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_EVENT_LISTENER); > > > + if (!ab) > > > + return; > > > + > > > + audit_log_format(ab, "auid=%d", > > > + from_kuid(&init_user_ns, > > > audit_get_loginuid(current))); + audit_log_format(ab, " uid=%d", > > > + from_kuid(&init_user_ns, current_uid())); > > > + audit_log_format(ab, " gid=%d", > > > + from_kgid(&init_user_ns, current_gid())); > > > + audit_log_format(ab, " ses=%d", audit_get_sessionid(current)); > > > + audit_log_format(ab, " pid=%d", task_pid_nr(current)); > > > + audit_log_format(ab, " comm="); > > > + audit_log_untrustedstring(ab, get_task_comm(comm, current)); > > > + if (mm) { > > > + down_read(&mm->mmap_sem); > > > + if (mm->exe_file) > > > + audit_log_d_path(ab, " exe=", > > > &mm->exe_file->f_path); > > > + up_read(&mm->mmap_sem); > > > + } else > > > + audit_log_format(ab, " exe=(null)"); > > > + audit_log_task_context(ab); /* subj= */ > > > > super crazy yuck. audit_log_task_info() ?? > > audit_log_task_info logs too much information for typical use. There are times > when you might want to know everything about what's connecting. But in this > case, we don't need anything about groups, saved uids, fsuid, or ppid. > > Its a shame we don't have a audit_log_task_info_light function which only > records: > > pid= auid= uid= subj= comm= exe= ses= tty= We already have audit_log_task() which gives: auid= uid= gid= ses= subj= pid= comm= exe= This is missing tty=, but has gid=. Can we please use that function instead and add tty=? And while we are at it, refactor audit_log_task_info() to call audit_log_task()? Is this standard set above what should be used for certain classes of log messages? Yes, it will be in a different order because we don't have a canonical order yet. Can we accept two orders of keywords so we can start canonicalizing, please?