Re: [RFC] netfilter: disable payload mangling in userns

[Florian Westphal <fw@strlen.de>]

Qi Tang <tpluszz77@gmail.com> wrote:
> I agree with the userns block.  I'll keep pushing the five
> consumer-side bounds-check patches: root in init userns can
> still install the same payload-set rule and trigger the same
> OOB at the re-read sites, so the underlying bug fix is still
> worth landing.
> 
> None of the five sites overlap with the relax wishlist (saddr/
> daddr, transport, linklayer).  Same class showed up in an
> earlier patch:
>   https://lore.kernel.org/netdev/20260514035802.1540395-1-tpluszz77@gmail.com/
> 
> These five are unlikely to be all of them; we think the
> consumer side warrants a broader audit.  Thoughts?

I think we have to do both.

For nft_payload/nft_exthdr:
1. Writes from !initial_userns are rejected (rule insert fails).
2. Writes for initial userns get validated at rule add time:
  - netdev ingress is allowed to alter everything, I think
  this is early enough to not introduce oddities that can't come
  from wire / untrusted peer.
 - bridge is allowed to alter everything: AFAICS there shouldn't
 be a problem with this, same as with ingress.
 - inet (ipv4/ip6): Check base (offset is unsigned and relative
   to ll/network header/transport header/payload
   - Allow modifications past transport header.
   - Allow modifications of transport header
   - Allow network header modifications for a subset of valid
     offsets/lengths: saddr, daddr, checksum, tos, id, ttl / hl.
     Reject everything else.
   - Allow link-layer; but check at from packetpath that
     offset + len don't write past start of the network header.
     Else: no-op.

nfqueue is the bigger problem: userspace gives us a whole new
packet data blob, not a delta that we should apply at offset x).

I think we have to update nfqueue to do rudimentary header revalidation
and drop the packet on failure, e.g. at least making sure tot_len is not
past skb->len.