[PATCH nf-next 0/5] nf_tables: rule deletion by description

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Rule deletion by description is a feature missing these days in
nf_tables that has been requested already several times by different
people.

I'm talking specifically of this feature that is available in iptables:

 # iptables -D INPUT -p tcp --dport 22 -j DROP

that allows us to delete the first rule matching this description.

So far, nf_tables allows users to delete rules through unique handle
numbers that you can list via -a option.

The approach I decided to follow adds most of this logic to userspace.
Basically, if the user wants to delete a given rule, the idea is to dump
the ruleset and compare if this rule matches any of the existing ones.
In case of matching found, annotate the rule handle and use it to delete
it from the kernel.

I noticed two corner cases that are problematic though:

1) A robot performs a rule deletion-after-addition from the same batch.
   This rule has no public u64 handle yet, therefore we cannot
   reference it. Add a new NFTA_RULE_ID, which is similar to NFTA_SET_ID
   in essence, that indicates an unique rule identifier inside the batch.
   This can be used to delete this rule not yet with the public handle.

1) Two threads compete to delete duplicated a rule. Even if duplicated
   rules make no sense, since the first rule would shadow the duplicated
   one, two robots inserting rules may lead us to this situation. Then,
   if robot A and robot B race to delete these duplicated rules, they may
   end up pointing to the same rule handle, so the one losing race will
   indicate that rule doesn't exist, while one of the two rules will
   still remain there, leaving the ruleset in inconsistent state.
   To catch this rare case, this patch introduces a way to validate
   what ruleset generation userspace expects to operate with. In case,
   kernel notices that userspace operates with a stale generation
   number, the kernel returns -ERESTART so userspace can transparently
   relookup for the rule handle.

I have a userspace patchset to implement rule deletion by description
for nft, still incomplete (I may push it to a branch though for
previous).  Main problem so far is that rule comparisons require that
the representation in both linearize and delinearize paths are the same.
This feature needs quite a bit of several userspace patches still
because there are a number of asymmetries in the rule representation
that need to be fixed, eg. I had to split bitfield transformations that
we're performing in the evaluation phase into a new specific step
between evaluation and linearization.

Another solution for this problem is to handle this entirely from
kernelspace. However, this is specifically cumbersome with anonymous
sets, that require a full comparison of all elements given that name are
meaningless. Moreover, on top of that, elements need to be ordered which
is not guaranteed when iterating over set backends such as hashtable. So
solving this from kernel look even more complex to me.

Let me know if you have any comment on these, thanks.

Pablo Neira Ayuso (5):
  netfilter: nfnetlink: get rid of u_intX_t types
  netfilter: nfnetlink: add nfnetlink_rcv_skb_batch()
  netfilter: nfnetlink: allow to check for generation ID
  netfilter: nf_tables: add check_genid to the nfnetlink subsystem
  netfilter: nf_tables: add NFTA_RULE_ID attribute

 include/linux/netfilter/nfnetlink.h      |  1 +
 include/net/netfilter/nf_tables.h        |  3 ++
 include/uapi/linux/netfilter/nf_tables.h |  2 +
 include/uapi/linux/netfilter/nfnetlink.h | 12 +++++
 net/netfilter/nf_tables_api.c            | 32 ++++++++++++
 net/netfilter/nfnetlink.c                | 90 +++++++++++++++++++++-----------
 6 files changed, 109 insertions(+), 31 deletions(-)

-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Netfitler Users]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux