Netdev Archive on lore.kernel.org help / color / mirror / Atom feed
From: Lukas Wunner <firstname.lastname@example.org> To: Daniel Borkmann <email@example.com> Cc: John Fastabend <firstname.lastname@example.org>, Pablo Neira Ayuso <email@example.com>, Jozsef Kadlecsik <firstname.lastname@example.org>, Florian Westphal <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Alexei Starovoitov <email@example.com>, Eric Dumazet <firstname.lastname@example.org>, Thomas Graf <email@example.com>, Laura Garcia <firstname.lastname@example.org>, David Miller <email@example.com> Subject: Re: [PATCH nf-next v3 3/3] netfilter: Introduce egress hook Date: Sun, 11 Oct 2020 09:59:05 +0200 [thread overview] Message-ID: <20201011075905.GA15225@wunner.de> (raw) In-Reply-To: <firstname.lastname@example.org> On Tue, Sep 08, 2020 at 02:55:36PM +0200, Daniel Borkmann wrote: > I would strongly prefer something where nf integrates into existing > tc hook, not only due to the hook reuse which would be better, > but also to allow for a more flexible interaction between tc/BPF > use cases [...] > one option to move forward [...] overall rework of ingress/egress > side to be a more flexible pipeline (think of cont/ok actions > as with tc filters or stackable LSMs to process & delegate). Interaction between netfilter and tc is facilitated by skb->mark. Both netfilter and tc are able to set and match by way of the mark. E.g. a netfilter hook may set the mark and tc may later perform an action if a matching mark is found. Because the placement of netfilter and tc hooks in the data path has been unchanged for decades, we must assume that users depend on their order for setting and matching the mark. Thus, reworking the data path in the way you suggest (a flexible pipeline) must not change the order of the hooks. It would have to be a fixed pipeline. But what's the benefit then compared to separate netfilter and tc hooks which are patched in at runtime and become NOPs if not used? (Which is what the present series is aiming for.) > to name one example... consider two different entities in the system > setting up the two, that is, one adding rules for nf ingress/egress > on the phys device for host fw and the other one for routing traffic > into/from containers at the tc layer, then traffic going into host ns > will hit nf ingress and on egress side the nf egress part; however, > traffic going to containers via existing tc redirect will not see the > nf ingress as expected but would on reverse path incorrectly > hit the nf egress one which is /not/ the case for dev_queue_xmit() today. Using tc to bounce ingress traffic into a container -- is that actually a thing or is it a hypothetical example? I think at least Docker uses plain vanilla routing and bridging to move packets in and out of containers. However you're right that if tc *is* used to redirect ingress packets to a container veth, then the data path would look like: host tc -> container tc -> container nft Whereas the egress data path would look like: container nft -> container tc -> host nft -> host tc But I argue that the egress data path is actually correct because the host must be able to firewall packets coming out of the container in case the container has been compromised. > And if you check a typical DHCP client that is present on major > modern distros like systemd-networkd's DHCP client then they > already implement filtering of malicious packets via BPF at > socket layer including checking for cookies in the DHCP header > that are set by the application itself to prevent spoofing . > >  https://github.com/systemd/systemd/blob/master/src/libsystemd-network/dhcp-network.c#L28 That's an *ingress* filter so that user space only receives DHCP packets and nothing else. We're talking about the ability to filter *egress* DHCP packets (among others) at the kernel level to guard against unwanted packets coming from user space. Thanks, Lukas
next prev parent reply other threads:[~2020-10-11 7:59 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-08-27 8:55 [PATCH nf-next v3 0/3] Netfilter egress hook Lukas Wunner 2020-08-27 8:55 ` [PATCH nf-next v3 1/3] netfilter: Rename ingress hook include file Lukas Wunner 2020-08-27 8:55 ` [PATCH nf-next v3 2/3] netfilter: Generalize ingress hook Lukas Wunner 2020-08-27 8:55 ` [PATCH nf-next v3 3/3] netfilter: Introduce egress hook Lukas Wunner 2020-08-28 18:52 ` John Fastabend 2020-09-03 5:00 ` John Fastabend 2020-09-04 8:54 ` Laura García Liébana 2020-09-04 15:46 ` John Fastabend 2020-09-05 11:13 ` Laura García Liébana 2020-09-04 16:21 ` Lukas Wunner 2020-09-04 21:14 ` Daniel Borkmann 2020-09-05 5:24 ` Lukas Wunner 2020-09-08 12:55 ` Daniel Borkmann 2020-09-11 7:42 ` Laura García Liébana 2020-09-11 16:27 ` Daniel Borkmann 2020-09-14 11:29 ` Laura García Liébana 2020-09-14 22:02 ` Daniel Borkmann 2020-09-17 10:28 ` Laura García Liébana 2020-09-18 20:31 ` Daniel Borkmann 2020-09-19 15:52 ` Pablo Neira Ayuso 2020-09-21 7:07 ` Laura García Liébana 2020-10-11 8:26 ` Lukas Wunner 2020-11-21 18:59 ` Pablo Neira Ayuso 2020-11-22 3:24 ` Alexei Starovoitov 2020-11-22 11:01 ` Pablo Neira Ayuso 2020-11-24 3:34 ` Alexei Starovoitov 2020-11-24 7:31 ` Lukas Wunner 2020-11-24 22:55 ` Alexei Starovoitov 2020-10-11 7:59 ` Lukas Wunner [this message] 2020-09-05 11:18 ` Laura García Liébana 2020-09-07 22:11 ` Daniel Borkmann 2020-09-08 6:19 ` Laura García Liébana 2020-09-08 11:46 ` Arturo Borrero Gonzalez 2020-09-08 13:27 ` Daniel Borkmann 2020-09-08 18:58 ` John Fastabend 2020-09-19 15:54 ` Pablo Neira Ayuso 2020-09-28 12:20 ` Lukas Wunner 2020-08-27 10:36 ` [PATCH nf-next v3 0/3] Netfilter " Laura García Liébana 2020-08-28 7:14 ` Daniel Borkmann 2020-08-28 9:14 ` Eric Dumazet
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20201011075905.GA15225@wunner.de \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).