netdev - Re: [RFC bpf-next 0/7] Programming socket lookup with BPF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 20 Jun 2019 13:56:46 +0200
From:   Florian Westphal <fw@...len.de>
To:     Jakub Sitnicki <jakub@...udflare.com>
Cc:     Florian Westphal <fw@...len.de>, netdev@...r.kernel.org,
        bpf@...r.kernel.org, kernel-team@...udflare.com
Subject: Re: [RFC bpf-next 0/7] Programming socket lookup with BPF

Jakub Sitnicki <jakub@...udflare.com> 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.