On Mon, Aug 22, 2016 at 06:22:20PM +0200, Daniel Mack wrote:
On 08/22/2016 06:06 PM, Pablo Neira Ayuso wrote:
quoted
On Fri, Aug 19, 2016 at 07:07:39PM +0200, Thomas Graf wrote:
quoted
quoted
You brought up multiple tables which reflect the cumulative approach.
This sometimes works but has its issues as well. Users must be aware
of each other and anticipate what rules other users might inject
before or after their own tables. The very existence of firewalld which
aims at democratizing this collaboration proves this point.
Firewalld, was really required in the iptables predefined tables
model, in nft last time we talked about this during NFWS'15, future
plans for firewalld were not clear yet.
Moreover, in nft, different users can indeed dump the ruleset and it
would be possible to validate if one policy is being shadowed by
another coming later on. The bpf bytecode dump cannot be taken to the
original representation.
But as Thomas said - both things address different use-cases. For
container setups, there is no administrator involved to use cli tools,
so I don't think that's really much of an argument.
quoted
quoted
So in that sense I would very much like for both models to be made
available to users. nftables+cgroups for a cumulative approach as
well as BPF+cgroups for the delegation approach. I don't see why the
cgroups based filtering capability should not be made available to both.
This patchset also needs an extra egress hook, not yet known where to
be placed, so two hooks in the network stacks in the end,
That should be solvable, I'm sure. I can as well leave egress out for
the next version so it can be added later on.
Any idea where you might put that yet? Does dev_xmit seems like a reasonable
place?
quoted
and this only works for cgroups version 2.
I don't see a problem with that, as v1 and v2 hierarchies can peacefully
coexist.
If someone uses the netprio, or the net classid controllers, skcd matches
no longer work. Ideally, we should fix up these controllers to make them
more v2 friendly.
quoted
Last time we talked about this, main concerns were that this was too
specific, but this approach seems even more specific to me.
Hmm, I disagree - bpf programs that are associated with cgroups are
rather something that can be extended a lot in the future, for instance
for handling port binding permissions etc. Unlike the proposed network
cgroup controller with all sorts of complicated knobs to control ranges
of ports etc, a bpf program that take care of that in a much more
versatile way.
I also strongly believe we can have both, a cgroup controller that has
bpf programs for socket filtering and other things, _and_ a "post socket
lookup netfilter" table type. Both will have their individual use-cases.
Thanks,
Daniel