Jakub Sitnicki <jakub@xxxxxxxxxxxxxx> wrote:
> > Sorry for the question, but where is the problem?
> > (i.e., is it with TPROXY or bpf side)?
>
> The way I see it is that the problem is that we have mappings for
> steering traffic into sockets split between two places: (1) the socket
> lookup tables, and (2) the TPROXY rules.
>
> BPF programs that need to check if there is a socket the packet is
> destined for have access to the socket lookup tables, via the mentioned
> bpf_sk_lookup helper, but are unaware of TPROXY redirects.
Oh, right.
[ TPROXY setup ]
Thanks for sharing, it will take me some time to digest this.
It would be good to have a simpler way to express this.
> One thing I haven't touched on in the cover letter is that to use TPROXY
> you need to set IP_TRANSPARENT on the listening socket. This requires
> that your process runs with CAP_NET_RAW or CAP_NET_ADMIN, or that you
> get the socket from systemd.
>
> I haven't been able to explain why the process needs to be privileged to
> receive traffic steered with TPROXY, but it turns out to be a pain point
> too. We end up having to lock down the service to ensure it doesn't use
> the elevated privileges for anything else than setting IP_TRANSPARENT.
Marek thinks its security measure:
1. TPROXY rule to redirect 80 to 8080 is added
2. UNPRIV binds 8080 -> Unpriv can then intercept packets for privileged
port (it can't, as TPROXY rule refuses to redirect to sk that did not
have IP_TRANSPARENT set).
AFAICS purely from stack pov, it sets IP_REPLY_ARG_NOSRCCHECK which in
turn sets FLOWI_FLAG_ANYSRC which bypasses a "fl->saddr is configured on
this machine" check in ip_route_output_key_hash_rcu.
I did not yet find similar entanglement for ipv6, will check.
