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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200123201541.emtse6l5wrnrpqgc@madcap2.tricolour.ca>
Date:   Thu, 23 Jan 2020 15:15:41 -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 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.

Next question, why do the other records generated from the test not
automatically trigger a syscall record when audit=1 on the kernel
command line?

> 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