From: David Ahern <dsahern@gmail.com>
To: Andy Lutomirski <luto@amacapital.net>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: "Andy Lutomirski" <luto@kernel.org>,
"Daniel Mack" <daniel@zonque.org>,
"Mickaël Salaün" <mic@digikod.net>,
"Kees Cook" <keescook@chromium.org>, "Jann Horn" <jann@thejh.net>,
"Tejun Heo" <tj@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
"Thomas Graf" <tgraf@suug.ch>,
"Michael Kerrisk" <mtk.manpages@gmail.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Linux API" <linux-api@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Network Development" <netdev@vger.kernel.org>
Subject: Re: Potential issues (security and otherwise) with the current cgroup-bpf API
Date: Mon, 19 Dec 2016 18:44:10 -0700 [thread overview]
Message-ID: <2dbec775-6304-e44c-19c5-fbf07877e7b1@gmail.com> (raw)
In-Reply-To: <CALCETrU1_bDVLfokQ7zasHVmeq7S-R+603GEw59V_wuj4eE1hw@mail.gmail.com>
On 12/19/16 5:25 PM, Andy Lutomirski wrote:
> net.socket_create_filter = "none": no filter
> net.socket_create_filter = "bpf:baadf00d": bpf filter
> net.socket_create_filter = "disallow": no sockets created period
> net.socket_create_filter = "iptables:foobar": some iptables thingy
> net.socket_create_filter = "nft:blahblahblah": some nft thingy
> net.socket_create_filter = "address_family_list:1,2,3": allow AF 1, 2, and 3
Such a scheme works for the socket create filter b/c it is a very simple use case. It does not work for the ingress and egress which allow generic bpf filters.
...
>> you're ignoring use cases I described earlier.
>> In vrf case there is only one ifindex it needs to bind to.
>
> I'm totally lost. Can you explain what this has to do with the cgroup
> hierarchy?
I think the point is that a group hierarchy makes no sense for the VRF use case. What I put into iproute2 is
cgrp2/vrf/NAME
where NAME is the vrf name. The filter added to it binds ipv4 and ipv6 sockets to a specific device index. cgrp2/vrf is the "default" vrf and does not have a filter. A user can certainly add another layer cgrp2/vrf/NAME/NAME2 but it provides no value since VRF in a VRF does not make sense.
...
>>> I like this last one, but IT'S NOT A POSSIBLE FUTURE EXTENSION. You
>>> have to do it now (or disable the feature for 4.10). This is why I'm
>>> bringing this whole thing up now.
>>
>> We don't have to touch user visible api here, so extensions are fine.
>
> Huh? My example in the original email attaches a program in a
> sub-hierarchy. Are you saying that 4.11 could make that example stop
> working?
Are you suggesting sub-cgroups should not be allowed to override the filter of a parent cgroup?
next prev parent reply other threads:[~2016-12-20 1:44 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-17 18:18 Potential issues (security and otherwise) with the current cgroup-bpf API Andy Lutomirski
2016-12-17 19:26 ` Mickaël Salaün
2016-12-17 20:02 ` Andy Lutomirski
2016-12-19 20:56 ` Alexei Starovoitov
2016-12-19 21:23 ` Andy Lutomirski
2016-12-20 0:02 ` Alexei Starovoitov
2016-12-20 0:25 ` Andy Lutomirski
2016-12-20 1:43 ` Andy Lutomirski
2016-12-20 1:44 ` David Ahern [this message]
2016-12-20 1:56 ` Andy Lutomirski
2016-12-20 2:52 ` David Ahern
2016-12-20 3:12 ` Andy Lutomirski
2016-12-20 4:44 ` Alexei Starovoitov
2016-12-20 5:27 ` Andy Lutomirski
2016-12-20 5:32 ` Alexei Starovoitov
2016-12-20 9:11 ` Peter Zijlstra
2017-01-03 10:25 ` Michal Hocko
2017-01-16 1:19 ` Tejun Heo
2017-01-17 13:03 ` Michal Hocko
2017-01-17 13:32 ` Peter Zijlstra
2017-01-17 13:58 ` Michal Hocko
2017-01-17 20:23 ` Andy Lutomirski
2017-01-18 22:18 ` Tejun Heo
2017-01-19 9:00 ` Michal Hocko
2016-12-20 3:18 ` Alexei Starovoitov
2016-12-20 3:50 ` Andy Lutomirski
2016-12-20 4:41 ` Alexei Starovoitov
2016-12-20 10:21 ` Daniel Mack
2016-12-20 17:23 ` Andy Lutomirski
2016-12-20 18:36 ` Daniel Mack
2016-12-20 18:49 ` Andy Lutomirski
2016-12-21 4:01 ` Alexei Starovoitov
2016-12-20 1:34 ` David Miller
2016-12-20 1:40 ` Andy Lutomirski
2016-12-20 4:51 ` Alexei Starovoitov
2016-12-20 5:26 ` Andy Lutomirski
2017-01-17 5:18 Andy Lutomirski
2017-01-18 22:41 ` Potential issues (security and otherwise) with the current cgroup-bpf API Tejun Heo
2017-01-19 0:18 ` Andy Lutomirski
2017-01-19 0:59 ` Tejun Heo
2017-01-19 2:29 ` Andy Lutomirski
2017-01-20 2:39 ` Alexei Starovoitov
2017-01-20 4:04 ` Andy Lutomirski
2017-01-23 4:31 ` Alexei Starovoitov
2017-01-23 20:20 ` Andy Lutomirski
2017-02-03 21:07 ` Andy Lutomirski
2017-02-03 23:21 ` Alexei Starovoitov
2017-02-04 17:10 ` Andy Lutomirski
2017-01-19 1:01 ` Mickaël Salaün
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=2dbec775-6304-e44c-19c5-fbf07877e7b1@gmail.com \
--to=dsahern@gmail.com \
--cc=alexei.starovoitov@gmail.com \
--cc=daniel@zonque.org \
--cc=davem@davemloft.net \
--cc=jann@thejh.net \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=mic@digikod.net \
--cc=mtk.manpages@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=tgraf@suug.ch \
--cc=tj@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).