Message-ID: <20200218212343.7wnbcupwzbo2b4td@madcap2.tricolour.ca>
Date:   Tue, 18 Feb 2020 16:23:43 -0500
From:   Richard Guy Briggs <rgb@...hat.com>
To:     Paul Moore <paul@...l-moore.com>
Cc:     Eric Paris <eparis@...isplace.org>, nhorman@...hat.com,
        Linux-Audit Mailing List <linux-audit@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH ghak28 V4] audit: log audit netlink multicast bind and
 unbind events

On 2020-01-23 16:45, Paul Moore wrote:
> On Thu, Jan 23, 2020 at 3:15 PM Richard Guy Briggs <rgb@...hat.com> wrote:
> > On 2020-01-23 14:07, Paul Moore wrote:
> > > On Thu, Jan 23, 2020 at 1:52 PM Richard Guy Briggs <rgb@...hat.com> wrote:
> > > > On 2020-01-23 11:57, Paul Moore wrote:
> > > > > On Thu, Jan 23, 2020 at 11:14 AM Richard Guy Briggs <rgb@...hat.com> wrote:
> > > > > > On 2020-01-23 09:32, Paul Moore wrote:
> > > > > > > On Wed, Jan 22, 2020 at 6:07 PM Richard Guy Briggs <rgb@...hat.com> wrote:
> > > > > > > > On 2020-01-22 17:40, Paul Moore wrote:
> > > > > > > > > On Fri, Jan 17, 2020 at 3:21 PM Richard Guy Briggs <rgb@...hat.com> 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.

The answer is in the ghak120 patch just posted.  See:
	https://github.com/linux-audit/audit-kernel/issues/120

As for the drop, well it appears that more than one termination records
are asynchronous (due to rcu locking) and will not have a directly
attributable syscall.  This applies to this issue and to ghak25.

> paul moore

- RGB

--
Richard Guy Briggs <rgb@...hat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635

Powered by blists - more mailing lists