Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 13 Feb 2020 09:29:43 -0500
From:   Richard Guy Briggs <rgb@redhat.com>
To:     Florian Westphal <fw@strlen.de>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Linux-Audit Mailing List <linux-audit@redhat.com>,
        netfilter-devel@vger.kernel.org, ebiederm@xmission.com,
        twoerner@redhat.com, eparis@parisplace.org, tgraf@infradead.org
Subject: Re: [PATCH ghak25 v2 8/9] netfilter: add audit operation field
Message-ID: <20200213142943.zxa6vwvl45q36zu6@madcap2.tricolour.ca>
References: <cover.1577830902.git.rgb@redhat.com>
 <6768f7c7d9804216853e6e9c59e44f8a10f46b99.1577830902.git.rgb@redhat.com>
 <20200106202306.GO795@breakpoint.cc>
 <20200213121410.b2dsh2kwg3k7xg7e@madcap2.tricolour.ca>
 <20200213123457.GO2991@breakpoint.cc>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200213123457.GO2991@breakpoint.cc>
User-Agent: NeoMutt/20180716
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 2020-02-13 13:34, Florian Westphal wrote:
> Richard Guy Briggs <rgb@redhat.com> wrote:
> > The default policy is NF_ACCEPT (because Rusty didn't want
> > more email, go figure...).  It occurred to me later that some table
> > loads took a command line parameter to be able to change the default
> > policy verdict from NF_ACCEPT to NF_DROP.  In particular, filter FORWARD
> > hook tables.  Is there a straightforward way to be able to detect this
> > in all the audit_nf_cfg() callers to be able to log it?  In particular,
> > in:
> > 	net/bridge/netfilter/ebtables.c: ebt_register_table()
> > 	net/bridge/netfilter/ebtables.c: do_replace_finish()
> > 	net/bridge/netfilter/ebtables.c: __ebt_unregister_table()
> > 	net/netfilter/x_tables.c: xt_replace_table()
> > 	net/netfilter/x_tables.c: xt_unregister_table()
> 
> The module parameter or the policy?
> 
> The poliy can be changed via the xtables tools.
> Given you can have:
> 
> *filter
> :INPUT ACCEPT [0:0]
> :FORWARD DROP [0:0]
> :OUTPUT ACCEPT [0:0]
> -A FORWARD -j ACCEPT
> COMMIT
> 
> ... which effectily gives a FORWARD ACCEPT policy I'm not sure logging
> the policy is useful.
> 
> Furthermore, ebtables has polices even for user-defined chains.
> 
> > Both potential solutions are awkward, adding a parameter to pass that
> > value in, but also trying to reach into the protocol-specific entry
> > table to find that value.  Would you have a recommendation?  This
> > assumes that reporting that default policy value is even desired or
> > required.
> 
> See above, I don't think its useful.  If it is needed, its probably best
> to define an informational struct containing the policy (accept/drop)
> value for the each hook points (prerouting to postrouting),  fill
> that from the backend specific code (as thats the only place that
> exposes the backend specific structs ...) and then pass that to
> the audit logging functions.

Ok, for this set, I'll drop the idea.  If it becomes apparent later than
it is necessary, it can be added as a field at the end of the record.

Thanks for looking at this.

- RGB

--
Richard Guy Briggs <rgb@redhat.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