On 08/19/2016 11:19 AM, Pablo Neira Ayuso wrote:
[...]
* During the Netfilter Workshop, the main concern to add this new socket
Don't really know what was discussed exactly at NFWS, but ...
ingress hook was that it is too specific. However this new hook in
the network stack looks way more specific more specific since *it only
works for cgroups*.
... why would that be something so overly specific? I don't think that "it
only works for cgroups" would be a narrow use case. While the current
sk_filter() BPF policies are set from application level, it makes sense to
me to have an option for an entity that manages the cgroups to apply an
external policy for networking side as well for participating processes.
It seems like a useful extension to the current sk_filter() infrastructure
iff we carve out the details properly and generic enough, and besides ...
[...]
On 08/19/2016 12:35 PM, Daniel Mack wrote:
[...]
So - I don't know. The whole 'eBPF in cgroups' idea was born because
through the discussions over the past months we had on all this, it
became clear to me that netfilter is not the right place for filtering
on local tasks. I agree the solution I am proposing in my patch set has
its downsides, mostly when it comes to transparency to users, but I
considered that acceptable. After all, we have eBPF users all over the
place in the kernel already, and seccomp, for instance, isn't any better
in that regard.
... since you mention seccomp here as well, it would be another good fit
as a program subtype to apply syscall policies for those participants on
a cgroup level too, f.e. to disallow certain syscalls. It would be quite
similar conceptually. So, fwiw, if this is being designed generic enough,
the use cases would go much broader than that.
Cheers,
Daniel