linux-kernel - Re: [PATCH ghak25 v2 8/9] netfilter: add audit operation field

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: <20200213123457.GO2991@breakpoint.cc>
Date:   Thu, 13 Feb 2020 13:34:57 +0100
From:   Florian Westphal <fw@...len.de>
To:     Richard Guy Briggs <rgb@...hat.com>
Cc:     Florian Westphal <fw@...len.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux-Audit Mailing List <linux-audit@...hat.com>,
        netfilter-devel@...r.kernel.org, ebiederm@...ssion.com,
        twoerner@...hat.com, eparis@...isplace.org, tgraf@...radead.org
Subject: Re: [PATCH ghak25 v2 8/9] netfilter: add audit operation field

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