Re: [PATCH ghak124 v1] audit: log nftables configuration change events
Richard Guy Briggs <rgb(a)redhat.com> wrote:
Well, we are only logging "some change", so is it necessary
to log the
generation count to show that? Is the generation count of specific
interest?
No, its of no specific interest. I just worded this poorly.
If the generation id increments, then something has been changed by the
batch, thats all.
> (After that, kernel can't back down anymore, i.e. all errors
are
> caught/handled beforehand).
I did think of recording all failed attempts too, but coding that would
be more effort. It is worth doing if it is deemed important,
particularly for permission issues (as opposed to resource limits or
packet format errors. This would be more of interest to a security
officer rather than a network technician, but the latter may find it
useful for debugging.
The permission check is done early, in nfnetlink_rcv() (search for
EPERM), you would need to add an audit call there if thats relevant
for audit purposes.
> If its 'any config change', then you also need to handle
adds
> or delete from sets/maps, since that may allow something that wasn't
> allowed before, e.g. consider
>
> ip saddr @trused accept
>
> and then, later on,
> nft add element ip filter @trusted { 10.0.0.0/8, 192.168.0.1 }
>
> This would not add a table, or chain, or set, but it does implicitly
> alter the ruleset.
Ah, ok, so yes, we would need that too. I see family and table in
there, op is evident. Is there a useful value we can use in the
"entries" field?
Maybe the handle of the set that the element was added to.
Each set, rule, chain, ... has a kernel-assigned number that
serves as a unique identifier.
> Is that record format expected to emit the current number of
chains?
I was aiming for a relevant value such as perhaps the new rule number or
the rule number being deleted.
In that case, use the handle, which is a u64 with a unique value (for a
given table).
> Since table names can be anything in nf_tables (they have no
special
> properties anymore), the table name is interesting from a informational
> pov, but not super interesting.
I don't think we need to be able to completely reconstruct the
tables/chains/rules from the information in the audit log, but be aware
of who is changing what when.
Ok. Have a look at nf_tables_fill_gen_info() in that case, you probably
want to emit at least the pid and task info, unless audit doesn't add
that already anyway.
> Consider a batch update that commits 100 new rules in chain x,
> this would result in 100 audit_log_nfcfg() calls, each with the
> same information.
So rule number would be a useful differentiator here.
Ok. Yes, that is available (rule->handle).