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

From: Richard Guy Briggs
Date: Tue Oct 21 2014 - 21:18:44 EST

On 14/10/21, Eric Paris wrote:
> On Tue, 2014-10-21 at 17:08 -0400, Richard Guy Briggs wrote:
> > 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@xxxxxxxxxx>
> > > > > ---
> > > > > 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?
>
> I've always hated the fact that we include this in ANY current audit
> message. I truly believe we need two new record types.
>
> AUDIT_PROCESS_INFO
> AUDIT_EXTENDED_PROCESS_INFO
>
> What does my UID have to do with a syscall? Why is it in the record?
> It's a pretty big change, like, RHEL8, but splitting the reporting of
> process info from other records will make all matter of things, in the
> kernel and in userspace so much cleaner...
>
> Nuts:
> type=SYSCALL msg=audit(10/13/2014 03:07:39.919:117953) : arch=x86_64 syscall=stat success=yes exit=0 a0=0x1332f60 a1=0x7fff8749e6d0 a2=0x7fff8749e6d0 a3=0x0 items=1 ppid=28212 pid=30066 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=367 comm=lsof exe=/usr/sbin/lsof subj=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023 key=(null)
>
> Slightly (and yes, just slightly) Less Nuts:
> type=SYSCALL msg=audit(10/13/2014 03:07:39.919:117953) : arch=x86_64 syscall=stat success=yes exit=0 a0=0x1332f60 a1=0x7fff8749e6d0 a2=0x7fff8749e6d0 a3=0x0
> type=AUDIT_PROCESS_INFO msg=audit(10/13/2014 03:07:39.919:117953) : pid=30066 auid=root uid=root gid=root tty=(none) ses=367 comm=lsof exe=/usr/sbin/lsof subj=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023 key=(null)
> type=AUDIT_EXTENDED_PROCESS_INFO msg=audit(10/13/2014 03:07:39.919:117953) : ppid=28212 euid=root suid=root fsuid=root egid=root sgid=root fsgid=root key=(null)
>
> It'd be weird is a syscall record actually only had syscall information....

I am definitely in favour of this approach.

- RGB

--
Richard Guy Briggs <rbriggs@xxxxxxxxxx>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/