On Mon, Aug 22, 2016 at 06:22:20PM +0200, Daniel Mack wrote: > 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. > Any idea where you might put that yet? Does dev_xmit seems like a reasonable place?
> > 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. > > 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 >
