[Ipchains-dev] My (newbie) thoughts about netfilter

[Paul Rusty Russell]

In message <E11LjEY-0006hW-00@mailgate.rz.uni-karlsruhe.de> you write:
> >I agree 8-(.  Would a `--rename-chain' option to iptables help?  It'd
> >be convoluted:
> 
> You'd be without an active chain for a second which could introduce
> race conditions (the chain to be replaced could be designed to take
> care of certain states and the rules following that chain chould rely
> on these states already taken out).

No, renaming them would be have no semantic change, so:

# iptables -N foo
# iptables -A INPUT -j foo
# iptables --rename foo bar

Is *exactly* the same as:

# iptables -N bar
# iptables -A INPUT -j bar

Basically, all it would gain you is that you wouldn't have to remember
which of your two chains was `active': it'd always be the one called
`active' after your script has run.

This is because inside the kernel we only have a table with jumps in
it: all the names etc. are an illusion maintained by the userspace
library, and not necessary for functioning (internally this is a huge
change over ipchains).

> If swapping rules is not possible, I'd have to have an additional
> --copy-chain option to iptables.

Swapping rules is possible, of course, as well.  It has the advantage
that it can have the unused `-S' flag, but the disadvantage that it's
fairly specific.

> This would make possible doing things like that.
> 
> # iptables --copy-chain A tmp
> # <make changes to tmp>
> # iptables --rename-chain tmp A
> 
> --rename-chain would need to overwrite any target chain that already
> exists and would need to delete the overwritten rules to prevent
> memory leaks. I don't have a clue how the table structure is
> implemented, but I strongly feel that race conditions in a packet
> filter are to be avoided at all costs.

You atomically replace the entire table every time, then you add
counters back in.  Hence, to insert a rule:

1) Read the rule table from the kernel:
	1 2 3 4 5

2) Create a new table with your rule inserted and counters zeroed:
	1 2 2' 3 4 5

3) Replace the rule table in the kernel (gives back the old counters
   atomically: c1 c2 c3 c4 c5).

4) Add these counters back in (c1 c2 0 c3 c4 c5).

This technique allows ANY atomic change you can come up with: we just
have to decide what abstractions to allow in the library.

> ># ipchains -A logdeny -j LIMIT --limit-rate 5 1
> 
> LIMIT would set a global limit for all LOG rules following it? Would
> it affect only the LOG rule following immediately?

[Oops, meant `iptables -A...', Doh!]

It would act as an accounting rule unless the limit is reached, when
it would act as a DROP rule (I'd probably make this configurable with
--limit-target).  Cool, huh?  This is just a simplification of the
existing RATE target (Jérôme de Vivie and Hervé Eychenne's excellent
work).

Rusty.
--
Hacking time.