Messages in this thread | | | Date | Thu, 13 Feb 2020 09:29:43 -0500 | From | Richard Guy Briggs <> | Subject | Re: [PATCH ghak25 v2 8/9] netfilter: add audit operation field |
| |
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
| |