Date:   Thu, 23 Jan 2020 11:13:49 -0500
From:   Richard Guy Briggs <rgb@...hat.com>
To:     Paul Moore <paul@...l-moore.com>
Cc:     nhorman@...hat.com, LKML <linux-kernel@...r.kernel.org>,
        Linux-Audit Mailing List <linux-audit@...hat.com>,
        Eric Paris <eparis@...isplace.org>
Subject: Re: [PATCH ghak28 V4] audit: log audit netlink multicast bind and
 unbind events

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.

> > The other is the disconnect record, shown above,
> > which may be asynchronous, or an unmonitored syscall (It could only be
> > setsockopt, close, shutdown.).
> 
> An unmonitored syscall still falls under the category of a
> configuration choice so I'm not too concerned about that, but the
> async disconnect record is legitimate.  Can you provide more
> information about when this occurs?  I'm guessing this is pretty much
> just an abrupt/abnormal program exit?

Again, what configuration choice are you talking about?  
"-a task,never"?  That isn't active on this system.

The output was produced by the test case quoted in the patch description.

I should not have had to put a rule in place to do syscall auditing on connect,
bind, setsockopt, close, shutdown.

The disconnect would have been due to a perl close() call.  I would not have
expected that to be async, but I don't know the details of what the perl
implementation does.

> > > I'm pretty sure these are the same arguments I made when Steve posted
> > > a prior version of this patch.
> >
> > You did.  I would really like to have dropped them, but they aren't
> > reliably available.
> 
> Personally I'm not too worried if we have duplicate information spread
> across records in a single event, as long as they are consistent.
> However, I remember Steve complaining rather loudly about duplicated
> fields across records in a single event some time back; perhaps that
> is not a concern of his anymore (perhaps it was a narrow case at the
> time), I don't know.
> 
> Here is the deal, either duplicated information is something we are
> okay with, or it is something to avoid; we need to pick one.  As
> mentioned above, I don't really care that much either way (I have a
> slight preference, but I don't feel strongly enough to fight for it),
> so let's hear the arguments both for and against and decide - whatever
> we pick I'll enforce so long as we are stuck with this string format.

Steve, can you say why this order should be the standard?  From:
	http://people.redhat.com/sgrubb/audit/record-fields.html

I get:
        SYSCALL/ANOM_LINK/FEATURE_CHANGE
                ppid    pid     auid    uid     gid     euid    suid    fsuid   egid    sgid    fsgid   tty     ses     comm    exe     subj
        ANOM_ABEND/SECCOMP
                                auid    uid     gid     ses     subj    pid     comm    exe
        LOGIN
                pid     uid     subj    old-auid        auid    tty     old-ses ses
        SYSTEM_BOOT/SYSTEM_SHUTDOWN
                pid     uid     auid    ses     subj    comm    exe
        USER_LOGIN
                pid     uid     auid    ses     subj    uid     exe
        DAEMON_START
                                auid    pid     uid     ses     subj
        DAEMON_CONFIG/DAEMON_END
                                auid    pid     subj
        ANOM_PROMISCUOUS
                                auid    uid     gid     ses
        52msgs
                pid     uid     auid    ses     subj	*
        CONFIG_CHANGE
                                auid    ses     subj

This new record is:
        EVENT_LISTENER
                pid     uid     auid    tty     ses     subj    comm    exe

And using the search criteria following, I get no other matches:
        /pid.*uid.*auid.*tty.*ses.*subj.*comm.*exe
so this appears to be a new field order.

> 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