linux-kernel - Re: [PATCH ghak25 v3 3/3] audit: add subj creds to NETFILTER

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: <20200318213327.ow22q6nnjn3ijq6v@madcap2.tricolour.ca>
Date:   Wed, 18 Mar 2020 17:33:27 -0400
From:   Richard Guy Briggs <rgb@...hat.com>
To:     Paul Moore <paul@...l-moore.com>
Cc:     Linux-Audit Mailing List <linux-audit@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        netfilter-devel@...r.kernel.org, twoerner@...hat.com,
        Eric Paris <eparis@...isplace.org>, fw@...len.de,
        ebiederm@...ssion.com, tgraf@...radead.org
Subject: Re: [PATCH ghak25 v3 3/3] audit: add subj creds to NETFILTER_CFG
 record to cover async unregister

On 2020-03-18 17:22, Paul Moore wrote:
> On Wed, Mar 18, 2020 at 9:12 AM Richard Guy Briggs <rgb@...hat.com> wrote:
> > On 2020-03-17 17:30, Richard Guy Briggs wrote:
> > > Some table unregister actions seem to be initiated by the kernel to
> > > garbage collect unused tables that are not initiated by any userspace
> > > actions.  It was found to be necessary to add the subject credentials to
> > > cover this case to reveal the source of these actions.  A sample record:
> > >
> > >   type=NETFILTER_CFG msg=audit(2020-03-11 21:25:21.491:269) : table=nat family=bridge entries=0 op=unregister pid=153 uid=root auid=unset tty=(none) ses=unset subj=system_u:system_r:kernel_t:s0 comm=kworker/u4:2 exe=(null)
> >
> > Given the precedent set by bpf unload, I'd really rather drop this patch
> > that adds subject credentials.
> >
> > Similarly with ghak25's subject credentials, but they were already
> > present and that would change an existing record format, so it isn't
> > quite as justifiable in that case.
> 
> Your comments have me confused - do you want this patch (v3 3/3)
> considered for merging or no?

I would like it considered for merging if you think it will be required
to provide enough information about the event that happenned.  In the
bpf unload case, there is a program number to provide a link to a
previous load action.  In this case, we won't know for sure what caused
the table to be unloaded if the number of entries was empty.  I'm still
trying to decide if it matters.  For the sake of caution I think it
should be included.  I don't like it, but I think it needs to be
included.

> 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