chain_cache

chain_cache

[Ozgur Akan]

is "chain_cache->end_off" the adress of last rule of the chain or end of 
the last rule(the place where a new rule will appended (like 
ipt_entry->next_offset))?

struct chain_cache
{
        char name[TABLE_MAXNAMELEN];
        /* This is the first rule in chain. */
        unsigned int start_off;
        /* Last rule in chain */
        unsigned int end_off;
};

thanks,

-- 
Ozgur Akan

Re: chain_cache

[Ozgur Akan]

no one knows?

Ozgur Akan wrote:

> is "chain_cache->end_off" the adress of last rule of the chain or end 
> of the last rule(the place where a new rule will appended (like 
> ipt_entry->next_offset))?
>
> struct chain_cache
> {
>        char name[TABLE_MAXNAMELEN];
>        /* This is the first rule in chain. */
>        unsigned int start_off;
>        /* Last rule in chain */
>        unsigned int end_off;
> };
>
> thanks,
>


-- 
Ozgur Akan

Re: chain_cache

[Henrik Nordstrom]

On Fri, 14 May 2004, Ozgur Akan wrote:

> no one knows?

Very few people if any is looking at or caring about how libiptc operates.  
What we care about is how the iptables kernel operate and that libiptc
succeds in building correct tables to the kernel.

The official interface to the iptables kernel is the iptables and 
iptables-save/restore commands, with their official module interfaces for 
writing your own matches/target extensions, the rest is "woodo magics" and 
is best left alone.

libiptc is primarily maintained for the purpose of implementing the above
commands and module interfaces, and other uses of the libiptc library is 
mostly on your own responsibility. It is expected there will be multiple 
memory leaks, odd bugs and other ill effects lurking around there.


iptables does not have a chain_cache. This is purely an artefact of the
libiptc userspace implementation for compiling/modifying the iptables
table before it is sent to the kernel.

Regards
Henrik

Re: chain_cache

[Henrik Nordstrom]

On Thu, 20 May 2004, Ozgur Akan wrote:

> I thought that if I will learn iptables kernel side, I have to learn 
> libiptc because libiptc is the lowest level interface to interact with 
> kernel that I can work on.

Not really interesting to most people. It is sufficient for most people to
say that this code compiles your supplied ruleset into an iptable and
inserts that table into the kernel.

> When we insert a rule with iptables command all checks are done with 
> iptables command itself. Does kernel do some checks and give error or 
> warning if one modifies iptables.c and try to insert buggy rules to 
> iptables?

See the checkentry functions of each target/match.

net/ipv4/netfilter/ip_tables.c also verifies the basic structure of the
iptable before it is accepted by the kernel. If you want to learn the gory
details see the following functions (in approximate call chain order), but
in fact most people only need to know that this code exists, not in 
detail how it works as it has no impact on how a packet is processed.

  translate_table
  check_entry_size_and_hooks
  check_entry
  ip_check_entry
  check_match
  checkentry function of each match used
  checkentry function of the target used

The purpose of all of this code until /* And one copy for every other CPU 
*/ in translate_table is to verify the sanity of the iptable sent 
from userspace.

It is worth remembering that iptables has it's name for a reason. The
ruleset in iptables is one single large table of rules (per table:  
filter, nat, mangle etc). Each modification you make to the ruleset
actually downloads the existing iptable from the kernel, compiles a new
iptable and uploads the new iptable to the kernel. Each hook then starts 
at predefined locations/chains within the compiled table when called from 
the Linux TCP/IP stack.

> Actually I have little idea about the journey of a packet in netfilter. 
> Beside reading ip_tables.c which sources or docs do you recommend me to 
> read?

In recommended order:

Packet Filtering Howto chapter 6

Netfilter Hacking Howto

The journey of a packet through the Linux 2.4.x network stack. 

skb - Linux network buffers (briefly, so you remember this later)

and most other documents linked from the Netfilter documentation page as 
you feel interesting.

Then where to go next depends on what you want to focus on. The internals
of ip_tables.c is not very sexy and not something most peple need to care
about other than understanding that it simply walks the chains of rules
when called from the different hooks. What most people is interesting in
learning more of is how the matches/targets works and how to extend
iptables with new functions. Here the best method is to study the existing
sources of an existing match/target, both in the kernel and userspace. For
example the mark match:

   ipt_mark.c    (kernel)
   ipt_mark.h    (kernel)
   libipt_mark.c (userspace)

Then there is connection tracking, NAT and many other functions more part 
of netfilter than iptables but equally interesting.

Regards
Henrik

Re: chain_cache

[Ozgur Akan]

Thanks for your detailed answer.

I commit my daily work on netfilter to http://netfilter.blogspot.com  
There is  useful information for  poeple who are interested in netfilter 
and want to learn netfilter internals step by step (actually with my 
steps ;) )

I plan to write a how-to about iptables.c in a few months by combining 
all of my daily works and writing them in more formal mode. I wish some 
people will be interested in it.

regards,

-- 
Ozgur Akan

Re: chain_cache

[Henrik Nordstrom]

On Thu, 20 May 2004, Ozgur Akan wrote:

> I commit my daily work on netfilter to http://netfilter.blogspot.com  
> There is  useful information for  poeple who are interested in netfilter 
> and want to learn netfilter internals step by step (actually with my 
> steps ;) )

After reading this I understand why you ask about chain_cache.

The task you are amiming at (detect duplicate rules) purely involves
modifying libiptc and requires a reasonable understanding of libiptc as 
you need to find the previous rule when inserting a new rule.. This is 
unfortunately not as easy as it may sound as the rules is managed in-place 
in their binary format and all you have is the offset where the new rule 
should be inserted.

The best place for to detect this is probably TC_INSERT_ENTRY. There you 
have a somewhat reasonable view of the chain in question and access to the 
binary rule representations.

Regards
Henrik

Re: chain_cache

[Ozgur Akan]

Henrik Nordstrom wrote:

>The task you are amiming at (detect duplicate rules) purely involves
>modifying libiptc and requires a reasonable understanding of libiptc as 
>you need to find the previous rule when inserting a new rule.. This is 
>unfortunately not as easy as it may sound as the rules is managed in-place 
>in their binary format and all you have is the offset where the new rule 
>should be inserted.
>

Yes after some study I understand that libiptc needs to be modified. 
When a rule is modified, deleted, appended or inserted we have to check 
the previous and next rule in the chain. (Of course for the first rule 
there will be no previous rule and for the last there will be no next 
rule, so append and insert 1 are easier to check)

>
>The best place for to detect this is probably TC_INSERT_ENTRY. There you 
>have a somewhat reasonable view of the chain in question and access to the 
>binary rule representations.
>  
>
What I think to do is to write a function to check previous and next 
rule. It may get an argument of -1 to check previous rule, 1 to check 
next rule and 0 to check both.

Also it may be a patch for insert_rules. insert_rules is used in all 
rule manuplation functions in libiptc.

I have not decided yet which solution will be the best but I am about to 
find it...

thank you for your comments.

regards,

-- 
Ozgur Akan

Re: chain_cache

[Henrik Nordstrom]

On Fri, 21 May 2004, Ozgur Akan wrote:

> Also it may be a patch for insert_rules. insert_rules is used in all 
> rule manuplation functions in libiptc.

Problem with insert_rule is that you do not have all the information about
which chain the rule is inserted into or the position within the chain,
just the offset within the whole table so you will have to deduce a lot of
information to be able to do this there.. it is possible, just a lot 
harder.

Regards
Henrik

Re: chain_cache

[Ozgur Akan]

Another problem is when we delete a rule the, the rule before the rule 
we deleted and the rule after the rule we deleted may be the same. This 
must be also checked. (I mean if we delete rule number 4, 3rd and 5th 
rules must be checked)  Because of this reason modificaiton of 
insert_rule is not enough.

I think writing a new function will be a better choice...

-- 
Ozgur Akan

Re: chain_cache

[Henrik Nordstrom]

On Fri, 21 May 2004, Ozgur Akan wrote:

> Another problem is when we delete a rule the, the rule before the rule 
> we deleted and the rule after the rule we deleted may be the same. This 
> must be also checked. (I mean if we delete rule number 4, 3rd and 5th 
> rules must be checked)  Because of this reason modificaiton of 
> insert_rule is not enough.

Not sure this is good. You do not want your ruleset to get rejected only
because you deleted another rule.

But what you could do if this is really what you want is to write a 
validator function which validates the table before it is uploaded to the 
kernel. This involves walking all the chains, and has the added benefit 
that it shold not be hard to add additional verifications later on.

Regards
Henrik