Re: [PATCH nf-next 0/3] netfilter: socket lookup function refactoring, cgroup match fixes

[Daniel Mack <daniel@zonque.org>]

Hi Pablo,

Thanks a lot for the feedback!

On 06/17/2015 03:03 AM, Pablo Neira Ayuso wrote:
> On Wed, Jun 17, 2015 at 02:08:09AM +0200, Daniel Mack wrote:
>> This series is based on work done by Daniel Borkmann a little while ago:
>>
>>   http://article.gmane.org/gmane.comp.security.firewalls.netfilter.devel/56877
>>
>> I addressed the feedback from that thread and factored out the socket
>> lookup code into own modules, one for ipv4, one for ipv6. These modules
>> are now selected in kbuild by code that uses it.
>>
>> Also, a patch was added to fix nft_meta cgroup match rules in a similar
>> fashion as it's now done for xt_cgroup.
> 
> Then, you probably missed these:
> 
> http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.devel/56879
> 
> That means that we will not take any rework of the existing socket
> infrastructure in netfilter/iptables. The socket match was designed
> for TPROXY, not for firewalling as it will only work under very
> specific assumptions.

Yeah, right. The thing is that cgroup matching is an incredible useful
feature. It's a pity it isn't currently usable for ingress packets.

> The possible ideas that we (Patrick and me) have discussed boil down to:
> 
> 1) Placing the INPUT hook at later stage, from the layer 4 protocols.

That would be great, but the consequences for other matching functions
are beyond my current knowledge of the netfilter code.

> or
> 
> 2) Add a new socket hook in the path from layer 4 protocols.
> 
> In both cases, the idea is that we're always 100% sure that we have a
> valid sk in place, including UDP multicast.

That sounds reasonable too. That option would at least work for nft
then, right? Is anyone working on that yet?


Thanks,
Daniel