Re: [PATCH ghak28 V4] audit: log audit netlink multicast bind and unbind events

On 2020-01-23 11:57, Paul Moore wrote: > On Thu, Jan 23, 2020 at 11:14 AM Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > > On 2020-01-23 09:32, Paul Moore wrote: > > > On Wed, Jan 22, 2020 at 6:07 PM Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > > > > On 2020-01-22 17:40, Paul Moore wrote: > > > > > On Fri, Jan 17, 2020 at 3:21 PM Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > > > > > > ... > > > > > > > > > diff --git a/kernel/audit.c b/kernel/audit.c > > > > > > index 17b0d523afb3..478259f3fa53 100644 > > > > > > --- a/kernel/audit.c > > > > > > +++ b/kernel/audit.c > > > > > > @@ -1520,20 +1520,60 @@ static void audit_receive(struct sk_buff *skb) > > > > > > audit_ctl_unlock(); > > > > > > } > > > > > > > > > > > > +/* 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; > > > > > > + > > > > > > + if (!audit_enabled) > > > > > > + return; > > > > > > + > > > > > > + ab = audit_log_start(audit_context(), GFP_KERNEL, AUDIT_EVENT_LISTENER); > > > > > > + if (!ab) > > > > > > + return; > > > > > > + > > > > > > + cred = current_cred(); > > > > > > + tty = audit_get_tty(); > > > > > > + audit_log_format(ab, "pid=%u uid=%u auid=%u tty=%s ses=%u", > > > > > > + task_pid_nr(current), > > > > > > + from_kuid(&init_user_ns, cred->uid), > > > > > > + from_kuid(&init_user_ns, audit_get_loginuid(current)), > > > > > > + tty ? tty_name(tty) : "(none)", > > > > > > + audit_get_sessionid(current)); > > > > > > > > > > Don't we already get all of that information as part of the syscall record? > > > > > > > > Yes. However, the syscall record isn't always present. One example is > > > > systemd, shown above. > > > > > > Assuming that the system supports syscall auditing, the absence of a > > > syscall record is a configuration choice made by the admin. If the > > > system doesn't support syscall auditing the obvious "fix" is to do the > > > work to enable syscall auditing on that platform ... but now we're > > > starting to get off topic. > > > > Well, the system did spit out a syscall record with the example above, > > so it has support for syscall auditing. > > > > I'm testing on f30 with an upstream kernel, the standard 30-stig ruleset and > > with kernel command line audit=1. What else is needed to support a syscall > > record on systemd before any audit rules have been put in place? We may still > > have a bug here that affects early process auditing. What am I missing? > > > > If we can get that sorted out, we don't need subject attributes in this record. > > It looks like some debugging is in order. There must be some sort of > action initiated by userspace which is causing the multicast > "op=connect", right? Find out what that is and why it isn't > generating a syscall record (maybe it's not a syscall? I don't know > what systemd is doing here). One clue is that subj=kernel and auid, ttye and ses are unset, despite the rest checking out: pid=1 uid=root auid=unset tty=(none) ses=unset subj=kernel comm=systemd exe=/usr/lib/systemd/systemd