From: Daniel Borkmann <daniel@iogearbox.net>
To: Daniel Mack <daniel@zonque.org>, Pablo Neira Ayuso <pablo@netfilter.org>
Cc: htejun@fb.com, ast@fb.com, davem@davemloft.net, kafai@fb.com,
fw@strlen.de, harald@redhat.com, netdev@vger.kernel.org
Subject: Re: [RFC PATCH 0/5] Add eBPF hooks for cgroups
Date: Fri, 19 Aug 2016 13:20:25 +0200 [thread overview]
Message-ID: <57B6EB79.50602@iogearbox.net> (raw)
In-Reply-To: <b2b52c47-c421-51fb-c4a1-c4f8a924f7aa@zonque.org>
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
next prev parent reply other threads:[~2016-08-19 11:20 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-17 14:00 [RFC PATCH 0/5] Add eBPF hooks for cgroups Daniel Mack
2016-08-17 14:00 ` [RFC PATCH 1/5] bpf: add new prog type for cgroup socket filtering Daniel Mack
2016-08-17 14:00 ` [RFC PATCH 2/5] cgroup: add bpf_{e,in}gress pointers Daniel Mack
2016-08-17 14:10 ` Tejun Heo
2016-08-17 17:50 ` Alexei Starovoitov
2016-08-17 17:56 ` Tejun Heo
2016-08-17 14:00 ` [RFC PATCH 3/5] bpf: add BPF_PROG_ATTACH and BPF_PROG_DETACH commands Daniel Mack
2016-08-17 14:20 ` Tejun Heo
2016-08-17 14:35 ` Daniel Mack
2016-08-17 15:06 ` Tejun Heo
2016-08-17 15:51 ` Daniel Mack
2016-08-17 17:48 ` Alexei Starovoitov
2016-08-17 15:08 ` Tejun Heo
2016-08-17 16:16 ` Eric Dumazet
2016-08-17 18:10 ` Alexei Starovoitov
2016-08-18 15:17 ` Daniel Mack
2016-08-17 14:00 ` [RFC PATCH 4/5] net: filter: run cgroup eBPF programs Daniel Mack
2016-08-17 14:23 ` Tejun Heo
2016-08-17 14:36 ` Daniel Mack
2016-08-17 14:58 ` Tejun Heo
2016-08-17 18:20 ` Alexei Starovoitov
2016-08-17 18:23 ` Alexei Starovoitov
2016-08-21 20:14 ` Sargun Dhillon
2016-08-25 19:37 ` Tejun Heo
2016-08-17 14:00 ` [RFC PATCH 5/5] samples: bpf: add userspace example for attaching eBPF programs to cgroups Daniel Mack
2016-08-19 9:19 ` [RFC PATCH 0/5] Add eBPF hooks for cgroups Pablo Neira Ayuso
2016-08-19 10:35 ` Daniel Mack
2016-08-19 11:20 ` Daniel Borkmann [this message]
2016-08-19 16:31 ` Pablo Neira Ayuso
2016-08-19 16:37 ` Thomas Graf
2016-08-19 16:21 ` Pablo Neira Ayuso
2016-08-19 17:07 ` Thomas Graf
2016-08-22 16:06 ` Pablo Neira Ayuso
2016-08-22 16:22 ` Daniel Mack
2016-08-22 17:20 ` Sargun Dhillon
2016-08-23 8:27 ` Daniel Mack
2016-08-23 9:54 ` Sargun Dhillon
2016-08-23 10:03 ` Daniel Mack
2016-08-19 16:01 ` Alexei Starovoitov
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=57B6EB79.50602@iogearbox.net \
--to=daniel@iogearbox.net \
--cc=ast@fb.com \
--cc=daniel@zonque.org \
--cc=davem@davemloft.net \
--cc=fw@strlen.de \
--cc=harald@redhat.com \
--cc=htejun@fb.com \
--cc=kafai@fb.com \
--cc=netdev@vger.kernel.org \
--cc=pablo@netfilter.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.