On 08/22/2016 06:06 PM, Pablo Neira Ayuso wrote: > On Fri, Aug 19, 2016 at 07:07:39PM +0200, Thomas Graf wrote:
>> 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. >> 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. > and this only works for cgroups version 2. I don't see a problem with that, as v1 and v2 hierarchies can peacefully coexist. > 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