On Thu, Nov 21, 2019 at 02:06:34PM +0100, Pablo Neira Ayuso wrote:
> On Wed, Nov 20, 2019 at 06:43:55PM +0100, Christian Göttsche wrote:
> > Labeling established and related packets requires the secmark to be stored in the connection.
> > Add the ability to store and retrieve secmarks like:
> > 
> >     ...
> >     chain input {
> >         ...
> > 
> >         # label new incoming packets
> >         ct state new meta secmark set tcp dport map @secmapping_in
> > 
> >         # add label to connection
> >         ct state new ct secmark set meta secmark
> > 
> >         # set label for est/rel packets from connection
> >         ct state established,related meta secmark set ct secmark
> > 
> >         ...
> >     }
> >     ...
> >     chain output {
> >         ...
> > 
> >         # label new outgoing packets
> >         ct state new meta secmark set tcp dport map @secmapping_out
> > 
> >         # add label to connection
> >         ct state new ct secmark set meta secmark
> > 
> >         # set label for est/rel packets from connection
> >         ct state established,related meta secmark set ct secmark
> > 
> >         ...
> >         }
> >     ...
> 
> I have applied this with minor changes on the evaluation side. Just
> follow up with another patch in case you find any issue.

Actually, I'm keeping back 2/4. I'm attaching the update I made.

I think it's good to disallow this:

        ct secmark 12
        meta secmark 12

but you also have to check from the evaluation phase that ct and meta
statements do not allow setting a constant value, ie.

        ct secmark set 12
        meta secmark set 12

From the objref statement evaluation step, you can check if this
expression is a constant through flags.

Thanks.