New target: can't delete rule

New target: can't delete rule

[Gervasio Bernal]

Hi all!!!!

I'm from Argentina and I'm developing a new target for iptables with a
college friend. This new target uses the Linux Cryptographic API.

We are debbuging the new extension and we noticed a rare behavior. 
First we inserted the rule like this:
#iptables -t mangle -A INPUT -s xxx.xxx.xxx.xxx -j NEW --param hello
And we don't have problems. 

The problem appears when we tried to erase the rule:
#iptables -t mangle -D INPUT -s xxx.xxx.xxx.xxx -j NEW --param hello
It says: :-(
iptables: No chain/target/match by that name

But, if we put this:
#iptables -t mangle -D INPUT 1
It erases correctly :-)

Why it works with a method and not with the another one?
It can be because we allocating memory in checkentry function and
freeing it  in destroy function?
How can we correct this rare behavior?

Thanks a lot.

Gervasio Bernal - Mendoza - Argentina
Pedro Deis - Mendoza - Argentina

Re: New target: can't delete rule

[Pablo Neira]

Gervasio Bernal wrote:
> I'm from Argentina and I'm developing a new target for iptables with a
> college friend. This new target uses the Linux Cryptographic API.
> 
> We are debbuging the new extension and we noticed a rare behavior. 
> First we inserted the rule like this:
> #iptables -t mangle -A INPUT -s xxx.xxx.xxx.xxx -j NEW --param hello
> And we don't have problems. 
> 
> The problem appears when we tried to erase the rule:
> #iptables -t mangle -D INPUT -s xxx.xxx.xxx.xxx -j NEW --param hello
> It says: :-(
> iptables: No chain/target/match by that name
> 
> But, if we put this:
> #iptables -t mangle -D INPUT 1
> It erases correctly :-)
> 
> Why it works with a method and not with the another one?
> It can be because we allocating memory in checkentry function and
> freeing it  in destroy function?
> How can we correct this rare behavior?

I bet that you have a pointer in the private info section of the target. 
See that iptables sets that pointer to NULL at rule creation. 
Afterwards, once checkentry() is called, such pointer won't be NULL anymore.

At removal, the rule built by iptables sets that pointer to NULL. Such 
rule will be compared with the ruleset hold in kernel space but no 
matches will be found since the pointers mismatch.

This problem is well known and it's very easy to fix up (look for 
userspacesize and offsetof in iptables/extensions). See ipt_limit, 
ipt_CLUSTERIP...

But it's *even* easier to figure out what's wrong with yout module if 
you post it here, in the mailing list.

--
Pablo

Re: New target: can't delete rule

[Patrick McHardy]

Pablo Neira wrote:
> I bet that you have a pointer in the private info section of the target.
> See that iptables sets that pointer to NULL at rule creation.
> Afterwards, once checkentry() is called, such pointer won't be NULL
> anymore.
> 
> At removal, the rule built by iptables sets that pointer to NULL. Such
> rule will be compared with the ruleset hold in kernel space but no
> matches will be found since the pointers mismatch.
> 
> This problem is well known and it's very easy to fix up (look for
> userspacesize and offsetof in iptables/extensions). See ipt_limit,
> ipt_CLUSTERIP...

Thanks, I didn't know about this problem. We should really focus on
a netlink interface to iptables once nf_conntrack is in, even without
pkttables.

Re: New target: can't delete rule

[Pablo Neira]

Patrick McHardy wrote:
> Thanks, I didn't know about this problem. We should really focus on
> a netlink interface to iptables once nf_conntrack is in, even without
> pkttables.

Should be really worthy the effort of implementing such netlink 
interface for iptables? I'm not too convinced. It'd be better if we 
spend our time implementing pkttables on top of netlink since it's meant 
to supersede all the functionalties provided by iptables. Anyway, I 
expect that there will be time to discuss this stuff during the workshop ;)

--
Pablo

Re: New target: can't delete rule

[Gervasio Bernal]

El mié, 07-09-2005 a las 22:30, Pablo Neira escribió:
> Gervasio Bernal wrote:
> > I'm from Argentina and I'm developing a new target for iptables with a
> > college friend. This new target uses the Linux Cryptographic API.
> > 
> > We are debbuging the new extension and we noticed a rare behavior. 
> > First we inserted the rule like this:
> > #iptables -t mangle -A INPUT -s xxx.xxx.xxx.xxx -j NEW --param hello
> > And we don't have problems. 
> > 
> > The problem appears when we tried to erase the rule:
> > #iptables -t mangle -D INPUT -s xxx.xxx.xxx.xxx -j NEW --param hello
> > It says: :-(
> > iptables: No chain/target/match by that name
> > 
> > But, if we put this:
> > #iptables -t mangle -D INPUT 1
> > It erases correctly :-)
> > 
> > Why it works with a method and not with the another one?
> > It can be because we allocating memory in checkentry function and
> > freeing it  in destroy function?
> > How can we correct this rare behavior?
> 
> I bet that you have a pointer in the private info section of the target. 
> See that iptables sets that pointer to NULL at rule creation. 
> Afterwards, once checkentry() is called, such pointer won't be NULL anymore.
> 
> At removal, the rule built by iptables sets that pointer to NULL. Such 
> rule will be compared with the ruleset hold in kernel space but no 
> matches will be found since the pointers mismatch.
> 
> This problem is well known and it's very easy to fix up (look for 
> userspacesize and offsetof in iptables/extensions). See ipt_limit, 
> ipt_CLUSTERIP...
> 
> But it's *even* easier to figure out what's wrong with yout module if 
> you post it here, in the mailing list.
> 
> --
> Pablo
> 

Pablo: 
    I did what you said, but I cannot make walk it. 

This is my libipt_CRYPT.c 

static struct iptables_target CRYPT 
= { 
    .name            = "CRYPT", 
    .version         = IPTABLES_VERSION, 
    .size            = IPT_ALIGN(sizeof(struct ipt_CRYPT_info)), 
    .userspacesize   = offsetof(struct ipt_CRYPT_info,
table_alloc_ptr),        
    .help            = &help, 
    .init            = &init, 
    .parse           = &parse, 
    .final_check     = &final_check, 
    .print           = &print, 
    .save            = &save, 
    .extra_opts      = opts 
}; 


This is my ipt_CRYPT.h 

struct ipt_CRYPT_info 
{ 
        char key[MAX_KEY_SIZE]; 
        unsigned int block_size; 
        unsigned int key_size; 

        struct tabla_alloc* table_alloc_ptr; 
}; 

struct tabla_alloc 
{ 
        struct crypto_tfm *tfm; 
        struct tabla_alloc* next; 
        struct tabla_alloc* ant; 
}; 

Greetings 

Re: New target: can't delete rule

[Pablo Neira]

Gervasio Bernal wrote:
>     I did what you said, but I cannot make walk it. 
> 
> This is my libipt_CRYPT.c 
> 
> static struct iptables_target CRYPT 
> = { 
>     .name            = "CRYPT", 
>     .version         = IPTABLES_VERSION, 
>     .size            = IPT_ALIGN(sizeof(struct ipt_CRYPT_info)), 
>     .userspacesize   = offsetof(struct ipt_CRYPT_info,
> table_alloc_ptr),        
>     .help            = &help, 
>     .init            = &init, 
>     .parse           = &parse, 
>     .final_check     = &final_check, 
>     .print           = &print, 
>     .save            = &save, 
>     .extra_opts      = opts 
> }; 
> 
> 
> This is my ipt_CRYPT.h 
> 
> struct ipt_CRYPT_info 
> { 
>         char key[MAX_KEY_SIZE]; 
>         unsigned int block_size; 
>         unsigned int key_size; 
> 
>         struct tabla_alloc* table_alloc_ptr; 
> }; 
> 
> struct tabla_alloc 
> { 
>         struct crypto_tfm *tfm; 
>         struct tabla_alloc* next; 
>         struct tabla_alloc* ant; 
> }; 

It looks fine. Which iptables version are you using? If my mind servers
well, I remember that there was a bug related with targets and the use
of userspacesize in old iptables versions (<= 1.3.1). If so, please try
with the lastest update.

--
Pablo

Re: New target: can't delete rule

[Gervasio Bernal]

Pablo Neira wrote:
> Gervasio Bernal wrote:
> 
>>     I did what you said, but I cannot make walk it.
>> This is my libipt_CRYPT.c
>> static struct iptables_target CRYPT = {     .name            =
>> "CRYPT",     .version         = IPTABLES_VERSION,     .size           
>> = IPT_ALIGN(sizeof(struct ipt_CRYPT_info)),     .userspacesize   =
>> offsetof(struct ipt_CRYPT_info,
>> table_alloc_ptr),            .help            = &help,    
>> .init            = &init,     .parse           = &parse,    
>> .final_check     = &final_check,     .print           = &print,    
>> .save            = &save,     .extra_opts      = opts };
>>
>> This is my ipt_CRYPT.h
>> struct ipt_CRYPT_info {         char key[MAX_KEY_SIZE];        
>> unsigned int block_size;         unsigned int key_size;
>>         struct tabla_alloc* table_alloc_ptr; };
>> struct tabla_alloc {         struct crypto_tfm *tfm;         struct
>> tabla_alloc* next;         struct tabla_alloc* ant; }; 
> 
> 
> It looks fine. Which iptables version are you using? If my mind servers
> well, I remember that there was a bug related with targets and the use
> of userspacesize in old iptables versions (<= 1.3.1). If so, please try
> with the lastest update.
> 
> -- 
> Pablo
> 

Yes, I have iptables version 1.3.1. I will try with one newer and I
comment to you.
Thanks again