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

On Thu, Jan 23, 2020 at 3:15 PM Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > On 2020-01-23 14:07, Paul Moore wrote: > > On Thu, Jan 23, 2020 at 1:52 PM Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > > > 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 > > > > Does Fedora use systemd in its initramfs (I'm guessing the answer is > > "yes")? If so, I wonder if that is the source of this record. > > Asking around, I got: "yes, dracut uses systemd these days" > > So, yes, that is the source of this record. > > So if there is no syscall associated with that record, it appears we > need those subject attributes. Well, I'm fairly certain that the record in question was the result of a syscall made by systemd, the question is why was it not recorded? That is something that needs to be answered.

paul moore