Re: [PATCH net 0/4] net/sched: reset conntrack after packet munging

[Florian Westphal <fw@strlen.de>]

Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> I apologize for the delayed response in the private exchange, but let
> me repeat my thoughts here...
> As you said, the munging can be done by an ebpf program (at different
> attachment points, not just cls/act using multiple helpers).

Yes, and that is ALSO buggy.  For BPF its even worse because if you
permit arbitrary writes at any point in the stack you will also
invalidate e.g. addresses/offsets stored in skb->cb[].

> "Packet rewrites are still possible with BPF. However, unlike pedit,
> that needs privileges in the initial namespace."
> That's only true in the default setup, but with BPF "token delegation"
> it no longer holds (will be reachable via unshare -Urn).
> 
> I have not tried to verify what i am claiming since we "last talked" -
> but could try it out when i get time (weekend looks promising).
> If what i am saying is true then you will have many places in ebpf to
> fix, which is not ideal.

*shrug*

> But even if not true, you can still do it with CAP_BPF - which leads
> to the same outcome. Unless we are saying as a general rule we should
> prioritize where/how we fix things based on whether they are
> reproducible via 1)namespace -urn  vs 2) require root permission
> (assume this includes CAP_BPF)

I think 2) is very different from 1).

> With that thought in mind, the question is: is there a single hook
> entry point where this could be done?

No.

> Example: nf_conntrack_in() or nf_confirm() as the choke point which
> catches all?

Those are too late.  You would need a new, unconditional sanitizer hook
at INT_MIN, in all of IPV4/IPV6/Bridge, plus additional code in core.c
to refuse installation of custom hooks before the sanitizer hook.

And that doesn't solve BPF (can sit anywhere) or OVS (no idea here if
its affected or not).