[PATCH] comment match port to pom-ng

[PATCH] comment match port to pom-ng

[Brad Fisher]

[-- Attachment #1: Type: text/plain, Size: 719 bytes --]

Attached is a tar file containing the comment match I wrote a while back
(Also posted before for old POM with no response:
http://marc.theaimsgroup.com/?l=netfilter-devel&m=107056927528485&w=2).
I've ported it to pom-ng, and it should work for 2.4 kernels fine.
Haven't tested 2.6 kernels, but will hopefully get a chance soon.

Simply extract the file at the pom-ng base dir and it should create the
comment/ dir structure.  For this patch to apply properly, you must
first apply the pom-ng patch I submitted to this list earlier today,
otherwise you'll end up with a half-patched kernel/userspace.

Please let me know if it is/is'nt acceptable for pom inclusion.  I'd
like to see it included someday...

-Brad Fisher

[-- Attachment #2: comment-pom-ng.tgz --]
[-- Type: application/x-unknown-content-type-WinRAR, Size: 2928 bytes --]

Re: [PATCH] comment match port to pom-ng

[Jozsef Kadlecsik]

Hi Brad,

On Wed, 12 May 2004, Brad Fisher wrote:

> Attached is a tar file containing the comment match I wrote a while back
> (Also posted before for old POM with no response:
> http://marc.theaimsgroup.com/?l=netfilter-devel&m=107056927528485&w=2).
> I've ported it to pom-ng, and it should work for 2.4 kernels fine.
> Haven't tested 2.6 kernels, but will hopefully get a chance soon.

Sorry, but could you demonstrate the necessity/usefulness of such a
feature? I tried to figure out at least one, but failed.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: [PATCH] comment match port to pom-ng

[Henrik Nordstrom]

On Fri, 14 May 2004, Jozsef Kadlecsik wrote:

> Sorry, but could you demonstrate the necessity/usefulness of such a
> feature? I tried to figure out at least one, but failed.

What I remember from last time this was discussed was that hte comment 
match allowed one to add inline comments within the iptable, eleminating 
the need of documenting the rules elsewhere.

Either you are of the view that iptables should be self-contained, then 
the comment match is quite useful. Or you are of the opinion that iptables 
should only care about what is needed to match/act on packets then the 
comment match is useless.

Myself consider me having one leg in each camp, and see why someone would
like to have a comment match to allow iptables-save etc to automatically
include some notes on why rules look like they do even if I would not
consider using such functions myself in production. However, I see some
quite useful debugging applications of a comment match in applications
automatically generating iptables ruleset to add some traces to how the
ruleset got build, especially if this is done in incremental steps not 
using a intermediary rule database between the update process and the 
kernel where these comments/trace information can be kept..

So bottom line, I don't see any reason why not to include a match like the
comment match in pom-ng. It would be even better if it could be done in a
way that does not add overhead to the execution of the iptable, but with
the design of iptables a match is unfortunately the closest approximation
available. I do however question if a comment match should be pushed 
forward to the main kernel.

Regards
Henrik

Re: [PATCH] comment match port to pom-ng

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

On Fri, May 14, 2004 at 11:09:55AM +0200, Jozsef Kadlecsik wrote:
> Hi Brad,
> 
> On Wed, 12 May 2004, Brad Fisher wrote:
> 
> > Attached is a tar file containing the comment match I wrote a while back
> > (Also posted before for old POM with no response:
> > http://marc.theaimsgroup.com/?l=netfilter-devel&m=107056927528485&w=2).
> > I've ported it to pom-ng, and it should work for 2.4 kernels fine.
> > Haven't tested 2.6 kernels, but will hopefully get a chance soon.
> 
> Sorry, but could you demonstrate the necessity/usefulness of such a
> feature? I tried to figure out at least one, but failed.

Jozsef, we have so many questionable or even useless (according to our
judgement) stuff in patch-o-matic, let's add the comment match with a
big warning (in source code, Kconfig, manpage and iptables --help), too.

Maybe we should add some kind of bitmask/flags to every pomng patchlet.
Something like POMNG_PATCHLET_UNWISE ;)

> Best regards,
> Jozsef


-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] comment match port to pom-ng

[Brad Fisher]

Jozsef Kadlecsik wrote:

> Sorry, but could you demonstrate the necessity/usefulness of such a
> feature? I tried to figure out at least one, but failed.

I believe Henrik's response to this pretty much sum it up - Thanks, Henrik.  I
guess the way I am currently using this match is to mark rules which are
automatically added so they can be recognized by my scripts if they need to
modify them.  I am currently modifying my rules on a rule-by-rule basis, and
have no intermediate storage of rule structure, so the tables must contain all
relevant information.  I wanted to make sure that I could manually add rules
and be certain that my scripts would not touch them, even if they did appear
to be similar.  One can build their rule structures so that most rules are in
separate application-specific chains, but there must always be hooks from some
pre-built chain to call the custom ones, and it's primarily for rules in those
chains that I use the match.  I relieves me from doing anything more
complicated than comparing for a specific pattern in the comment.  Without it,
I'd be forced to compare all elements of the rules (ie. src, dst, matches,
etc.) just to make sure it was one my script added - and even then it wouldn't
be certain.

On a related note: I had proposed at one time an 'application' match (see:
http://marc.theaimsgroup.com/?l=netfilter-devel&m=105234664704023&w=2), so I
could do the same, but the idea for the 'comment' match that was brough up
suited my needs just as well and is more flexible/general.

I don't know if the reasons mentioned above are good enough for pom inclusion,
but I'd like to see it happen.  As far as inclusion in the stock kernel, I
guess I wouldn't feel too bad if it never made it there as long as it was in
pom.

> Best regards,
> Jozsef

Thanks,
Brad Fisher

Re: [PATCH] comment match port to pom-ng

[Jozsef Kadlecsik]

Hi Brad,

On Mon, 17 May 2004, Brad Fisher wrote:

> Jozsef Kadlecsik wrote:
>
> > Sorry, but could you demonstrate the necessity/usefulness of such a
> > feature? I tried to figure out at least one, but failed.
>
> I believe Henrik's response to this pretty much sum it up - Thanks, Henrik.  I
> guess the way I am currently using this match is to mark rules which are
> automatically added so they can be recognized by my scripts if they need to
> modify them.  I am currently modifying my rules on a rule-by-rule basis, and
> have no intermediate storage of rule structure, so the tables must contain all
> relevant information.  I wanted to make sure that I could manually add rules
> and be certain that my scripts would not touch them, even if they did appear
> to be similar.  One can build their rule structures so that most rules are in
> separate application-specific chains, but there must always be hooks from some
> pre-built chain to call the custom ones, and it's primarily for rules in those
> chains that I use the match.  I relieves me from doing anything more
> complicated than comparing for a specific pattern in the comment.  Without it,
> I'd be forced to compare all elements of the rules (ie. src, dst, matches,
> etc.) just to make sure it was one my script added - and even then it wouldn't
> be certain.

Please, don't get me wrong, but I still don't understand how it can be
used.

If you generate your rules from some kind of policy by a meta-language,
then if you want to add an additional rule permanently, then you add it
both to the policy and the running kernel. If you don't want to add it
permanently, then you don't add it to the policy. The same can be done
when you work with a script. You write, that custom rules can be added
to pre-defined chains, used as entry points just for custom rules. What
can't I see properly in your case?

> On a related note: I had proposed at one time an 'application' match (see:
> http://marc.theaimsgroup.com/?l=netfilter-devel&m=105234664704023&w=2), so I
> could do the same, but the idea for the 'comment' match that was brough up
> suited my needs just as well and is more flexible/general.
>
> I don't know if the reasons mentioned above are good enough for pom inclusion,
> but I'd like to see it happen.  As far as inclusion in the stock kernel, I
> guess I wouldn't feel too bad if it never made it there as long as it was in
> pom.

There are more dangerous patches lying around in pom, that's not the
problem. I'd like to understand the driving force behind such a ridiculous
feature :-)

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: [PATCH] comment match port to pom-ng

[Henrik Nordstrom]

On Mon, 17 May 2004, Jozsef Kadlecsik wrote:

> If you generate your rules from some kind of policy by a meta-language,
> then if you want to add an additional rule permanently, then you add it
> both to the policy and the running kernel. If you don't want to add it
> permanently, then you don't add it to the policy. The same can be done
> when you work with a script. You write, that custom rules can be added
> to pre-defined chains, used as entry points just for custom rules. What
> can't I see properly in your case?

Some may find adding "comment" information to the rule rather than
creating a jump to a custom chain better documents the rule and makes
maintenance easier.

One extreme example is an automated tool running on a chain of rules which
MAY also contain rules of other source. By using the comment field the
application can differentiate between it's own rules and rules of other
source.  Yes, in most if not all cases the same can be done with a custom
chain and a jump, but if you need very many differentiations of rules then
this can result in a ridicoulus amount of custom chains with just one or
two rules in them..

In addition the comment can be used to identify the source for the rule
when there is multiple applications modifying the iptable.  Consider for
example a firewall consisting of both a static policy and dynamic rules
carefully weighted. The comment can then be used to indicate the source of
the rule (policy, dynamic action X, dynamic action Y etc..)

Another interesting application is when adding temporary rules outside of 
the permanent policy. By using a comment it is easy to give some form of 
indication why the rule is there and when it should be removed.

And as I said earlier it makes even more sense if the firewall policy is
maintained using iptables-save/restore such as is the case in several
distributions. The comment then automatically gets saved into the policy
by iptables-save and eleminates the need for the administrator to keep 
separate records of the firewall rules.

Regards
Henrik

Re: [PATCH] comment match port to pom-ng

[Brad Fisher]

> On Mon, 17 May 2004, Jozsef Kadlecsik wrote:
>
> > If you generate your rules from some kind of policy by a meta-language,
> > then if you want to add an additional rule permanently, then you add it
> > both to the policy and the running kernel. If you don't want to add it
> > permanently, then you don't add it to the policy. The same can be done
> > when you work with a script. You write, that custom rules can be added
> > to pre-defined chains, used as entry points just for custom rules. What
> > can't I see properly in your case?

Basically, this sounds like there is some sort of intermediate storage of the
rule structure going on beyond iptables/netfilter.

Whenever a rule is changed, the meta-language would need to be updated to
reflect that change.  For example, when a rule is added manually via the
iptables command the meta-language may need to be updated to reflect new rule
positions.  I see no good/easy way to enforce this.  Without enforcement, how
can you be sure a comment attached to a rule via your meta-language accurately
represents the current state of the ruleset?  In fact, how can you guarantee
that the rules represented by your meta-language accurately represent the
current state of the ruleset?  With the comment match, you can be sure since
they are a part of the rule itself.

My scripts do not rebuild the entire ruleset, nor do they assume that they are
in full control of the ruleset.  They try to be as non-invasive as possible,
and use the comment match to try to enforce that by attaching comments with
specific and easy to recognize patterns to any rules created in built-in
chains.  Only rules with comments matching those patterns will be modified
later.

> Henrik Nordstrom wrote:

> Some may find adding "comment" information to the rule rather than
> creating a jump to a custom chain better documents the rule and makes
> maintenance easier.
>
> One extreme example is an automated tool running on a chain of rules which
> MAY also contain rules of other source. By using the comment field the
> application can differentiate between it's own rules and rules of other

... SNIP ...

> distributions. The comment then automatically gets saved into the policy
> by iptables-save and eleminates the need for the administrator to keep
> separate records of the firewall rules.
>
> Regards
> Henrik

I couldn't have said it any better.  I had a big long reply typed up and
decided to trash it after Henrik sent this :)

-Brad Fisher

Re: [PATCH] comment match port to pom-ng

[Jozsef Kadlecsik]

On Wed, 12 May 2004, Brad Fisher wrote:

> Attached is a tar file containing the comment match I wrote a while back
> (Also posted before for old POM with no response:
> http://marc.theaimsgroup.com/?l=netfilter-devel&m=107056927528485&w=2).
> I've ported it to pom-ng, and it should work for 2.4 kernels fine.
> Haven't tested 2.6 kernels, but will hopefully get a chance soon.

Patch is added to pom-ng. :-)
It is marked as for 2.4 only in the info file, because it won't work with
2.6 (API changed).

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: [PATCH] comment match port to pom-ng

[Brad Fisher]

Jozsef Kadlecsik wrote:

> On Wed, 12 May 2004, Brad Fisher wrote:
>
> > Attached is a tar file containing the comment match I wrote a while back
> > (Also posted before for old POM with no response:
> > http://marc.theaimsgroup.com/?l=netfilter-devel&m=107056927528485&w=2).
> > I've ported it to pom-ng, and it should work for 2.4 kernels fine.
> > Haven't tested 2.6 kernels, but will hopefully get a chance soon.
>
> Patch is added to pom-ng. :-)
> It is marked as for 2.4 only in the info file, because it won't work with
> 2.6 (API changed).

Thanks!  I'll try to get a 2.6 version of the patch together then :)  BTW, is
there any 2.6 specific documentation out there beyond the source?

> Best regards,
> Jozsef

-Brad Fisher