MARK targets all non-terminating

MARK targets all non-terminating

[Jan Engelhardt]

Hi,


I'll keep it terse: why are xt_MARK, xt_CONNMARK and friends all using 
XT_CONTINUE instead of NF_DROP? It makes it particularly hard to write 
classification:

-t mangle -A POSTROUTING -d 134.76.0.0/16 -j CLASSIFY --set-class 1:10
-t mangle -A POSTROUTING -p tcp -j CLASSIFY --set-class 1:11

Will mark all TCP traffic to 134.76.0.0/16 as 1:11 instead of 1:10. 
Instead, one needs to fiddle and fiddle and end up with:

-t mangle -N class10
-t mangle -A class10 -j CLASSIFY --set-class 1:10
-t mangle -N class11
-t mangle -A class11 -j CLASSIFY --set-class 1:11

-t mangle -A POSTROUTING -d 134.76.0.0/16 -g class10
-t mangle -A POSTROUTING -p tcp -g class11

This non-terminating behavior of [file list] is _NOT_ documented in the 
iptables manpage. Is it even intended at all?


[file list:]
18:37 ichi:../net/netfilter > grep XT_CONTINUE *.c
xt_CLASSIFY.c:  return XT_CONTINUE;
xt_CONNMARK.c:  return XT_CONTINUE;
xt_CONNSECMARK.c:       return XT_CONTINUE;
xt_MARK.c:      return XT_CONTINUE;
xt_MARK.c:      return XT_CONTINUE;
xt_NOTRACK.c:           return XT_CONTINUE;
xt_NOTRACK.c:   return XT_CONTINUE;
xt_SECMARK.c:   return XT_CONTINUE;

ipt_TOS.c:    return IPT_CONTINUE;
ipt_TTL.c:    return IPT_CONTINUE;
(and to a certain degree ipt_TCPMSS, possibly others)


	-`J'
-- 

Re: MARK targets all non-terminating

[Tom Eastep]

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

Jan Engelhardt wrote:

> 
> This non-terminating behavior of [file list] is _NOT_ documented in the 
> iptables manpage. Is it even intended at all?
> 

A couple of observations:

a) This non-terminating behavior has been around since the MARK targets first
   appeared so existing tools and scripts depend on it. As an example, if
   "-j MARK" were suddenly terminating, most current uses of
   "-j CONNMARK --save-mark" would cease working since they typically
   follow matching "-j MARK" rules.
   
c) ebtables provides a nice solution which allows "-j mark" to be either
   terminating (the default), or non-terminating depending on the
   inclusion of a "--mark-target" phrase. That would be a nice addition
   to the iptables MARK targets, so long as the default was CONTINUE
   rather than ACCEPT.

-Tom 
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: MARK targets all non-terminating

[Jan Engelhardt]

On Jan 2 2007 10:25, Tom Eastep wrote:
>> 
>> This non-terminating behavior of [file list] is _NOT_ documented in the 
>> iptables manpage. Is it even intended at all?
>
>A couple of observations:
>
>a) This non-terminating behavior has been around since the MARK targets first
>   appeared so existing tools and scripts depend on it. As an example, if
>   "-j MARK" were suddenly terminating, most current uses of
>   "-j CONNMARK --save-mark" would cease working since they typically
>   follow matching "-j MARK" rules.
>   
>c) ebtables provides a nice solution which allows "-j mark" to be either
>   terminating (the default), or non-terminating depending on the
>   inclusion of a "--mark-target" phrase. That would be a nice addition
>   to the iptables MARK targets, so long as the default was CONTINUE
>   rather than ACCEPT.

I was about to extend the kernel and iptables to support something along the
lines of

  iptables -t mangle -A POSTROUTING -j MARK --mark 117 --terminate

but then faced the problem of what verdict to return in xt_MARK when
--terminate is given. NF_DROP? No, that could possibly interfere
with the default chain policy. Same goes for NF_ACCEPT. NF_STOLEN,
NF_QUEUE and NF_STOP do not seem to be the right ones either. We'd
need some sort of NF_EXIT in ipt_do_table, which essentially jumps
right out of all user-defined chains to the end of the table to hit
the default policy. ip_tables.c already is quite strech-intended (5
and more, according to CodingStyle, you're bust) and adding more code
would make it worse.

What is the right approach (as in "DTRT") the nf developers can
suggest to implement a target terminating like this?


Thanks,
Jan
-- 

Re: MARK targets all non-terminating

[Jozsef Kadlecsik]

Hi,

On Sun, 7 Jan 2007, Jan Engelhardt wrote:

> I was about to extend the kernel and iptables to support something along the
> lines of
>
>  iptables -t mangle -A POSTROUTING -j MARK --mark 117 --terminate
>
> but then faced the problem of what verdict to return in xt_MARK when
> --terminate is given. NF_DROP? No, that could possibly interfere
> with the default chain policy. Same goes for NF_ACCEPT. NF_STOLEN,
> NF_QUEUE and NF_STOP do not seem to be the right ones either. We'd
> need some sort of NF_EXIT in ipt_do_table, which essentially jumps
> right out of all user-defined chains to the end of the table to hit
> the default policy.

Why should the processing be continued? If the packet is to be marked then 
it's highly unlikley it should at the same time be dropped. So in my 
opinion a simple NF_ACCEPT would be a perfect return value.

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: MARK targets all non-terminating

[Jan Engelhardt]

On Jan 8 2007 08:56, Jozsef Kadlecsik wrote:
> On Sun, 7 Jan 2007, Jan Engelhardt wrote:
>
>> I was about to extend the kernel and iptables to support
>> something along the lines of
>> 
>> iptables -t mangle -A POSTROUTING -j MARK --mark 117 --terminate
>> 
>> but then faced the problem of what verdict to return in xt_MARK when
>> --terminate is given. NF_DROP? No, that could possibly interfere
>> with the default chain policy. Same goes for NF_ACCEPT. NF_STOLEN,
>> NF_QUEUE and NF_STOP do not seem to be the right ones either. We'd
>> need some sort of NF_EXIT in ipt_do_table, which essentially jumps
>> right out of all user-defined chains to the end of the table to hit
>> the default policy.
>
> Why should the processing be continued? If the packet is
> to be marked then it's highly unlikley it should at the
> same time be dropped. So in my opinion a simple NF_ACCEPT
> would be a perfect return value.

That makes sense. Thanks for the hint, I think I can
complete it now.


[ Gah, I just dislike it that you can actually *filter*
  packets in the "mangle" and "nat" tables. This leads to
  things like users doing just that (nat especially because
  it only gets the first packet in a connection. To me, it
  looks like mangle-input and filter-input could just be
  consolidated into one table, same going for
  mangle-forward/filter-forward.

  http://www.imagestream.com/~josh/PacketFlow-new.png ]



	-`J'
-- 

Re: MARK targets all non-terminating

[Jan Engelhardt]

On Jan 8 2007 22:42, Jan Engelhardt wrote:
>On Jan 8 2007 08:56, Jozsef Kadlecsik wrote:
>> On Sun, 7 Jan 2007, Jan Engelhardt wrote:
>>
>>> I was about to extend the kernel and iptables to support
>>> something along the lines of
>>> 
>>> iptables -t mangle -A POSTROUTING -j MARK --mark 117 --terminate
>>> 
>>> but then faced the problem of what verdict to return in xt_MARK when
>>> --terminate is given. NF_DROP? [...]
>>
>> Why should the processing be continued? If the packet is to be
>> marked then it's highly unlikley it should at the same time be
>> dropped. So in my opinion a simple NF_ACCEPT would be a perfect
>> return value.
>
>That makes sense. Thanks for the hint, I think I can
>complete it now.

Uhm, considering what you just said I think we don't even need
--terminate, but just e.g.

-N markme
-A markme -j LOG
-A markme -j MARK --mark 117
-A markme -j ACCEPT
-t mangle -A POSTROUTING -m matchSomething -j markme

What do you think?


	-`J'
-- 

Re: MARK targets all non-terminating

[Jozsef Kadlecsik]

On Tue, 9 Jan 2007, Jan Engelhardt wrote:

>>> Why should the processing be continued? If the packet is to be
>>> marked then it's highly unlikley it should at the same time be
>>> dropped. So in my opinion a simple NF_ACCEPT would be a perfect
>>> return value.
>>
>> That makes sense. Thanks for the hint, I think I can
>> complete it now.
>
> Uhm, considering what you just said I think we don't even need
> --terminate, but just e.g.
>
> -N markme
> -A markme -j LOG
> -A markme -j MARK --mark 117
> -A markme -j ACCEPT
> -t mangle -A POSTROUTING -m matchSomething -j markme
>
> What do you think?

The question is, how many chains you have to define just for the MARK + 
ACCEPT actions and wether you accept it as a solution.

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: MARK targets all non-terminating

[Jan Engelhardt]

On Jan 10 2007 09:21, Jozsef Kadlecsik wrote:
> On Tue, 9 Jan 2007, Jan Engelhardt wrote:
>> 
>> Uhm, considering what you just said I think we don't even need
>> --terminate, but just e.g.
>> 
>> -N markme
>> -A markme -j LOG
>> -A markme -j MARK --mark 117
>> -A markme -j ACCEPT
>> -t mangle -A POSTROUTING -m matchSomething -j markme
>> 
>> What do you think?
>
> The question is, how many chains you have to define just for the
> MARK + ACCEPT

One per mark target.

> actions and wether you accept it as a solution.

I happened to see shadowing CLASSIFY rules in the corporate
fw, so I thought "dude, you need to terminate here". Since
corp uses fwbuilder, I don't care as much if it takes a lot
of rules to implement MARK-and-terminate. However, in a
different project of my own[1], I really want to keep rules
to a minimum, even if it's a little contrary to netfilter
practice.

Perhaps I'll write the --terminate thing up just for the
fun of it, unless someone else does it before me.

[1] http://lists.netfilter.org/pipermail/netfilter-devel/2007-January/026537.html


Jan
-- 

Re: MARK targets all non-terminating

[Amin Azez]

* Jan Engelhardt wrote, On 09/01/07 22:09:

> Uhm, considering what you just said I think we don't even need
> --terminate, but just e.g.
> 
> -N markme
> -A markme -j LOG
> -A markme -j MARK --mark 117
> -A markme -j ACCEPT
> -t mangle -A POSTROUTING -m matchSomething -j markme
> 
> What do you think?
> 
> 
> 	-`J'

It's not just mark and terminate, but mark and return.
It can be managed with --goto and -j RETURN and a subchain.

-N markme
-A markme -j LOG
-A markme -j MARK --mark 117
-A markme -j RETURN
-t mangle -A checkthings -m matchSometing --goto markme

The design of the iptables-xml schema supports this for multiple-target
rules.

Things get a bit more complicated if you want round-tripping, the only
reason I haven't built it in to the xsltproc I submitted is because once
of our client applications still talks to iptables directly and expects
the full matches to be repeated for each target.

But if a chain-name prefix is used to indicate that it's contents are
mutiple targets for a single match then it will be easy to gather them
back into a single rule with multiple targets when re-generating the xml.

iptables rules aren't the most expressive but the system is flexible.

Sam

Re: MARK targets all non-terminating

[Jan Engelhardt]

On Jan 10 2007 12:11, Amin Azez wrote:
>
>It's not just mark and terminate, but mark and return.
>It can be managed with --goto and -j RETURN and a subchain.

That is not the issue here. We _do_ want to terminate. Consider this faulty
(shadowing) ruleset:

-t mangle -A POSTROUTING -s 10.0.0.0 -j CLASSIFY --set-class 1:16
-t mangle -A POSTROUTING -p tcp -j CLASSIFY --set-class 1:17

which will cause TCP traffic to 10.0.0.0 become 1:17 rather than the intended
1:16. Using an extra chain with ACCEPT solves it, with RETURN: no.

(Have a look at
http://sourceforge.net/tracker/index.php?func=detail&aid=1618381&group_id=5314&atid=105314
for the motivation to 'fix' CLASSIFY and friends)

>-N markme
>-A markme -j LOG
>-A markme -j MARK --mark 117
>-A markme -j RETURN
>-t mangle -A checkthings -m matchSometing --goto markme
>
>The design of the iptables-xml schema supports this for multiple-target
>rules.

13:15 ichi:/home/jengelh # iptables -I INPUT -j MARK -j RETURN
iptables v1.3.7: multiple -j flags not allowed

-A POSTROUTING -p tcp -m tcp --dport 999 -j MARK --set-mark 0x11 -j RETURN
COMMIT
# Completed on Wed Jan 10 13:16:01 2007

File x.ipt saved
13:16 ichi:/dev/shm # iptables-restore <x.ipt 
iptables-restore v1.3.7: multiple -j flags not allowed


Sorry, but if iptables-restore can't do it, I doubt xml will.


	-`J'
-- 

Re: MARK targets all non-terminating

[Patrick McHardy]

Jan Engelhardt wrote:
> On Jan 10 2007 12:11, Amin Azez wrote:
> 
>>It's not just mark and terminate, but mark and return.
>>It can be managed with --goto and -j RETURN and a subchain.
> 
> 
> That is not the issue here. We _do_ want to terminate. Consider this faulty
> (shadowing) ruleset:
> 
> -t mangle -A POSTROUTING -s 10.0.0.0 -j CLASSIFY --set-class 1:16
> -t mangle -A POSTROUTING -p tcp -j CLASSIFY --set-class 1:17
> 
> which will cause TCP traffic to 10.0.0.0 become 1:17 rather than the intended
> 1:16. Using an extra chain with ACCEPT solves it, with RETURN: no.

It does if you use a subchain as Amin suggested, and it allows you to
do additional mangling.

Re: MARK targets all non-terminating

[Jan Engelhardt]

On Jan 10 2007 13:56, Patrick McHardy wrote:
>> 
>> -t mangle -A POSTROUTING -s 10.0.0.0 -j CLASSIFY --set-class 1:16
>> -t mangle -A POSTROUTING -p tcp -j CLASSIFY --set-class 1:17
>> 
>> which will cause TCP traffic to 10.0.0.0 become 1:17 rather than the intended
>> 1:16. Using an extra chain with ACCEPT solves it, with RETURN: no.
>
>It does if you use a subchain as Amin suggested, and it allows you to
>do additional mangling.

Well the problem with RETURN is that you may run into another MARK or 
CLASSIFY (see above) which is not intended. You actually resurfaced an 
idea of mine, namely... consider this:

 -s IP -j MARK --set-mark 17
 -p tcp -j MARK --set-mark 18

to make them not overlap, one could use

 -p tcp -m mark --mark 0 -j MARK --set-mark 18

But unfortunately, there is no "classify" match for the CLASSIFY case. 
What now? You don't really want to matrixify all possibilities - 
consider:

 -s IP1 -j MARK --set-mark 17 --term
 -d IP2 -j MARK --set-mark 18 --term
 -p tcp --dport 22 -j MARK --set-mark 19 --term
 -p tcp -j MARK --set-mark 20 --term

then you would need to matrixify it where '--term' is not available

  -s    -d  tcp?  22?  action
  ip1  ip2    y    y  MARK 17
  ip1  ip2    y    n  MARK 17
  ip1  ip2    n    y  MARK 17
  ip1  ip2    n    n  MARK 17
  ip1 !ip2  ...   ..  MARK 17
 !ip1
 .
 .

leading to

 -s IP1 ! -d IP2 -j MARK --set-mark 17
 ! -s IP1 -d IP2 -j MARK --set-mark 18
 ! -s IP1 ! -d IP2 -p tcp --dport 22 -j MARK --set-mark 19
 ! -s IP1 ! -d IP2 -p tcp ! --dport 22 -j MARK --set-mark 20

well, this obviously becomes ugly quickly.
Phew, I hope I did not mix up anything.


	-`J'
-- 

Re: MARK targets all non-terminating

[Amin Azez]

* Jan Engelhardt wrote, On 10/01/07 14:00:
> On Jan 10 2007 13:56, Patrick McHardy wrote:
>>> -t mangle -A POSTROUTING -s 10.0.0.0 -j CLASSIFY --set-class 1:16
>>> -t mangle -A POSTROUTING -p tcp -j CLASSIFY --set-class 1:17
>>>
>>> which will cause TCP traffic to 10.0.0.0 become 1:17 rather than the intended
>>> 1:16. Using an extra chain with ACCEPT solves it, with RETURN: no.
>> It does if you use a subchain as Amin suggested, and it allows you to
>> do additional mangling.
> 
> Well the problem with RETURN is that you may run into another MARK or 
> CLASSIFY (see above) which is not intended.

If you only call one level deep, and --goto the subchain, then RETURN is
the same as terminate-with-policy-action, surely?	

-j RETURN [n] to return multiple levels is on _my_ todo list.
I also consider -j RETURN NAME to return back until it finds NAME'd
chain in the call stack. (it's ugly because it presumes that a the
returned-from chain will always be called from a known chain).

These may not solve your problem, but --goto and 1 level deep might help
for now.

Sam

Re: MARK targets all non-terminating

[Jan Engelhardt]

On Jan 10 2007 14:17, Amin Azez wrote:
>
>If you only call one level deep, and --goto the subchain, then RETURN is
>the same as terminate-with-policy-action, surely?	

Yes indeed. But what if... you were to match two conditions, i.e.
if(src != 10.1.2.3 && src != 192.168.0.1) { classify; }
You could not just jump out of it, you'd need RETURN n.

>-j RETURN [n] to return multiple levels is on _my_ todo list.

Seems like it.

>I also consider -j RETURN NAME to return back until it finds NAME'd
>chain in the call stack. (it's ugly because it presumes that a the
>returned-from chain will always be called from a known chain).

What if there is no such chain in the return addresses?


	-`J'
-- 

Re: MARK targets all non-terminating

[Amin Azez]

* Jan Engelhardt wrote, On 08/01/07 21:42:

> That makes sense. Thanks for the hint, I think I can
> complete it now.
> 
> 
> [ Gah, I just dislike it that you can actually *filter*
>   packets in the "mangle" and "nat" tables. This leads to
>   things like users doing just that (nat especially because
>   it only gets the first packet in a connection. To me, it
>   looks like mangle-input and filter-input could just be
>   consolidated into one table, same going for
>   mangle-forward/filter-forward.
> 
>   http://www.imagestream.com/~josh/PacketFlow-new.png ]


Yes please!

Sam