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