Re: [regression] Completely editing packet should be allowed.

[Florian Westphal <fw@strlen.de>]

allfox wy <allfoxwy@gmail.com> wrote:
> Florian Westphal wrote:
> > The NAT dispatch uses the l4proto value from the tuple to decide
> > what to do.
> >
> > So as far as I can see NAT postrouting will write updated tcp/udp
> > port to the packet, which is no longer udp/tcp - corrupting
> > the l4 header.
> 
> Excuse me for that I should be more clear about this part.
> The scheme is working by IP-in-IP encapsulation. The layer 4 protocol
> is another IP and it does not have a port number. TCP/UDP is in layer
> 5 in this scheme.

Yes, but kernel doesn't know that.

static bool l4proto_manip_pkt(struct sk_buff *skb,
                              unsigned int iphdroff, unsigned int hdroff,
                              const struct nf_conntrack_tuple *tuple,
                              enum nf_nat_manip_type maniptype)
{
        switch (tuple->dst.protonum) {  <- from BEFORE nfqueue rewrite 
        case IPPROTO_TCP:
                return tcp_manip_pkt(skb, iphdroff, hdroff,
                                     tuple, maniptype);
        case IPPROTO_UDP:
                return udp_manip_pkt(skb, iphdroff, hdroff,
                                     tuple, maniptype);

so, when the conntrack entry is subject to a port translation, the
nat engine will now write into the 2nd ip header that follows the
first one, this will corrupt ip->ihl, version, tos and/or tot_len
fields.

> The design:
> Incoming packets => got deciphered in PREROUTING of RAW => CONNTRACK
> see real contents => all the normal
> Outgoing packets => CONNTRACK see real contents => enciphered in
> POSTROUTING of MANGLE => MASQUERADE based on earlier CONNTRACK
> information
> 
> The problem:
> I can no longer change L4-protocol number in layer 3 IP header during
> encipher/decipher process because of Kernel commit 112e447

Yes.  Not yet sure how to make this work.  Changing this part of
NAT engine isn't sufficient either, conntrack entry could have
a helper attached, and those do not re-validate tcp header sizes
or ip options.

Maybe best we can do is to relax the check for initial user
namespace (or just init_net).  But it would still allow
CAP_NET_ADMIN process to re-gain all other capabilities...