Re: [nf PATCH v2 1/2] net: nf_tables: Make nft_meta expression more robust

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Fri, Jul 19, 2019 at 06:35:21PM +0200, Pablo Neira Ayuso wrote:
> On Fri, Jul 19, 2019 at 02:39:20PM +0200, Phil Sutter wrote:
> > nft_meta_get_eval()'s tendency to bail out setting NFT_BREAK verdict in
> > situations where required data is missing breaks inverted checks
> > like e.g.:
> > 
> > | meta iifname != eth0 accept
> > 
> > This rule will never match if there is no input interface (or it is not
> > known) which is not intuitive and, what's worse, breaks consistency of
> > iptables-nft with iptables-legacy.
> > 
> > Fix this by falling back to placing a value in dreg which never matches
> > (avoiding accidental matches):
> > 
> > {I,O}IF:
> > 	Use invalid ifindex value zero.
> > 
> > {BRI_,}{I,O}IFNAME, {I,O}IFKIND:
> > 	Use an empty string which is neither a valid interface name nor
> > 	kind.
> > 
> > {I,O}IFTYPE:
> > 	Use ARPHRD_VOID (0xFFFF).
> 
> What could it be done with?
> 
> NFT_META_BRI_IIFPVID
> NFT_META_BRI_IIFPVPROTO
> 
> Those will still not work for
> 
>         meta ibrpvid != 40
> 
> if interface is not available.
> 
> For VPROTO probably it's possible. I don't have a solution for
> IIFPVID.

VLAN IDs 0 and 4095 are reserved, we could use those. I refrained from
changing bridge VLAN matches because of IIFPVPROTO, no idea if there's
an illegal value we could use for that. If you have an idea, I'm all for
it. :)

Thanks, Phil



[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux