Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Fri, Feb 3, 2017 at 3:21 PM, Alexei Starovoitov wrote: > On Fri, Feb 03, 2017 at 01:07:39PM -0800, Andy Lutomirski wrote: >> >> Is there any plan to address this? If not, I'll try to write that >> patch this weekend. > > yes. I'm working on 'disallow program

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Fri, Feb 3, 2017 at 3:21 PM, Alexei Starovoitov wrote: > On Fri, Feb 03, 2017 at 01:07:39PM -0800, Andy Lutomirski wrote: >> >> Is there any plan to address this? If not, I'll try to write that >> patch this weekend. > > yes. I'm working on 'disallow program override' flag. > It got stalled,

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Fri, Feb 03, 2017 at 01:07:39PM -0800, Andy Lutomirski wrote: > > Is there any plan to address this? If not, I'll try to write that > patch this weekend. yes. I'm working on 'disallow program override' flag. It got stalled, because netns discussion got stalled. Later today will send a patch

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Fri, Feb 03, 2017 at 01:07:39PM -0800, Andy Lutomirski wrote: > > Is there any plan to address this? If not, I'll try to write that > patch this weekend. yes. I'm working on 'disallow program override' flag. It got stalled, because netns discussion got stalled. Later today will send a patch

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Jan 23, 2017 at 12:20 PM, Andy Lutomirski wrote: > On Sun, Jan 22, 2017 at 8:31 PM, Alexei Starovoitov > wrote: >> On Thu, Jan 19, 2017 at 08:04:59PM -0800, Andy Lutomirski wrote: >>> restricting the types of sockets that can be created,

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Jan 23, 2017 at 12:20 PM, Andy Lutomirski wrote: > On Sun, Jan 22, 2017 at 8:31 PM, Alexei Starovoitov > wrote: >> On Thu, Jan 19, 2017 at 08:04:59PM -0800, Andy Lutomirski wrote: >>> restricting the types of sockets that can be created, then you do want >>> the filter to work across

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Sun, Jan 22, 2017 at 8:31 PM, Alexei Starovoitov wrote: > On Thu, Jan 19, 2017 at 08:04:59PM -0800, Andy Lutomirski wrote: >> On Thu, Jan 19, 2017 at 6:39 PM, Alexei Starovoitov >> wrote: >> > On Wed, Jan 18, 2017 at 06:29:22PM

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Sun, Jan 22, 2017 at 8:31 PM, Alexei Starovoitov wrote: > On Thu, Jan 19, 2017 at 08:04:59PM -0800, Andy Lutomirski wrote: >> On Thu, Jan 19, 2017 at 6:39 PM, Alexei Starovoitov >> wrote: >> > On Wed, Jan 18, 2017 at 06:29:22PM -0800, Andy Lutomirski wrote: >> >> I think it could work by

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Thu, Jan 19, 2017 at 08:04:59PM -0800, Andy Lutomirski wrote: > On Thu, Jan 19, 2017 at 6:39 PM, Alexei Starovoitov > wrote: > > On Wed, Jan 18, 2017 at 06:29:22PM -0800, Andy Lutomirski wrote: > >> I think it could work by making a single socket cgroup controller

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Thu, Jan 19, 2017 at 08:04:59PM -0800, Andy Lutomirski wrote: > On Thu, Jan 19, 2017 at 6:39 PM, Alexei Starovoitov > wrote: > > On Wed, Jan 18, 2017 at 06:29:22PM -0800, Andy Lutomirski wrote: > >> I think it could work by making a single socket cgroup controller that > >> handles all cgroup

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Thu, Jan 19, 2017 at 6:39 PM, Alexei Starovoitov wrote: > On Wed, Jan 18, 2017 at 06:29:22PM -0800, Andy Lutomirski wrote: >> I think it could work by making a single socket cgroup controller that >> handles all cgroup things that are bound to a socket. Using > >

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Thu, Jan 19, 2017 at 6:39 PM, Alexei Starovoitov wrote: > On Wed, Jan 18, 2017 at 06:29:22PM -0800, Andy Lutomirski wrote: >> I think it could work by making a single socket cgroup controller that >> handles all cgroup things that are bound to a socket. Using > > Such 'socket cgroup

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Wed, Jan 18, 2017 at 06:29:22PM -0800, Andy Lutomirski wrote: > I think it could work by making a single socket cgroup controller that > handles all cgroup things that are bound to a socket. Using Such 'socket cgroup controller' would limit usability of the feature to sockets and force all

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Wed, Jan 18, 2017 at 06:29:22PM -0800, Andy Lutomirski wrote: > I think it could work by making a single socket cgroup controller that > handles all cgroup things that are bound to a socket. Using Such 'socket cgroup controller' would limit usability of the feature to sockets and force all

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Wed 18-01-17 14:18:50, Tejun Heo wrote: > Hello, Michal. > > On Tue, Jan 17, 2017 at 02:58:30PM +0100, Michal Hocko wrote: > > This would require using hierarchical cgroup iterators to iterate over > > It does behave hierarchically. > > > tasks. As per Andy's testing this doesn't seem to be

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Wed 18-01-17 14:18:50, Tejun Heo wrote: > Hello, Michal. > > On Tue, Jan 17, 2017 at 02:58:30PM +0100, Michal Hocko wrote: > > This would require using hierarchical cgroup iterators to iterate over > > It does behave hierarchically. > > > tasks. As per Andy's testing this doesn't seem to be

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Wed, Jan 18, 2017 at 4:59 PM, Tejun Heo wrote: > Hello, Andy. > > On Wed, Jan 18, 2017 at 04:18:04PM -0800, Andy Lutomirski wrote: >> To map cgroup -> hook, a simple array in each cgroup structure works. >> To map (cgroup, netns) -> hook function, the natural approach would be

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Wed, Jan 18, 2017 at 4:59 PM, Tejun Heo wrote: > Hello, Andy. > > On Wed, Jan 18, 2017 at 04:18:04PM -0800, Andy Lutomirski wrote: >> To map cgroup -> hook, a simple array in each cgroup structure works. >> To map (cgroup, netns) -> hook function, the natural approach would be >> to have some

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On 19/01/2017 01:18, Andy Lutomirski wrote: >>> it explicitly respects the cgroup hierarchy. It shows up in >>> /proc/cgroups, and I had no problem mounting a cgroupfs instance with >>> perf_event enabled. So I'm not sure what you mean. >> >> That all it's doing is providing membership

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On 19/01/2017 01:18, Andy Lutomirski wrote: >>> it explicitly respects the cgroup hierarchy. It shows up in >>> /proc/cgroups, and I had no problem mounting a cgroupfs instance with >>> perf_event enabled. So I'm not sure what you mean. >> >> That all it's doing is providing membership

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

Hello, Andy. On Wed, Jan 18, 2017 at 04:18:04PM -0800, Andy Lutomirski wrote: > To map cgroup -> hook, a simple array in each cgroup structure works. > To map (cgroup, netns) -> hook function, the natural approach would be > to have some kind of hash, and that would be slower. This code is >

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

Hello, Andy. On Wed, Jan 18, 2017 at 04:18:04PM -0800, Andy Lutomirski wrote: > To map cgroup -> hook, a simple array in each cgroup structure works. > To map (cgroup, netns) -> hook function, the natural approach would be > to have some kind of hash, and that would be slower. This code is >

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Wed, Jan 18, 2017 at 2:41 PM, Tejun Heo wrote: > Helloo, Andy. > > On Mon, Jan 16, 2017 at 09:18:36PM -0800, Andy Lutomirski wrote: >> Perhaps this is a net feature, though, not a cgroup feature. This >> would IMO make a certain amount of sense. Iptables cgroup matches, >>

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Wed, Jan 18, 2017 at 2:41 PM, Tejun Heo wrote: > Helloo, Andy. > > On Mon, Jan 16, 2017 at 09:18:36PM -0800, Andy Lutomirski wrote: >> Perhaps this is a net feature, though, not a cgroup feature. This >> would IMO make a certain amount of sense. Iptables cgroup matches, >> for example,

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

Helloo, Andy. On Mon, Jan 16, 2017 at 09:18:36PM -0800, Andy Lutomirski wrote: > Perhaps this is a net feature, though, not a cgroup feature. This > would IMO make a certain amount of sense. Iptables cgroup matches, > for example, logically are an iptables (i.e., net) feature. The Yeap. >

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

Helloo, Andy. On Mon, Jan 16, 2017 at 09:18:36PM -0800, Andy Lutomirski wrote: > Perhaps this is a net feature, though, not a cgroup feature. This > would IMO make a certain amount of sense. Iptables cgroup matches, > for example, logically are an iptables (i.e., net) feature. The Yeap. >

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

Hello, Michal. On Tue, Jan 17, 2017 at 02:58:30PM +0100, Michal Hocko wrote: > This would require using hierarchical cgroup iterators to iterate over It does behave hierarchically. > tasks. As per Andy's testing this doesn't seem to be the case. I haven't That's not what Andy's testing showed.

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

Hello, Michal. On Tue, Jan 17, 2017 at 02:58:30PM +0100, Michal Hocko wrote: > This would require using hierarchical cgroup iterators to iterate over It does behave hierarchically. > tasks. As per Andy's testing this doesn't seem to be the case. I haven't That's not what Andy's testing showed.

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Tue, Jan 17, 2017 at 5:58 AM, Michal Hocko wrote: > On Tue 17-01-17 14:32:04, Peter Zijlstra wrote: >> On Tue, Jan 17, 2017 at 02:03:03PM +0100, Michal Hocko wrote: >> > On Sun 15-01-17 20:19:01, Tejun Heo wrote: >> > [...] >> > > So, what's proposed is a proper part of bpf.

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Tue, Jan 17, 2017 at 5:58 AM, Michal Hocko wrote: > On Tue 17-01-17 14:32:04, Peter Zijlstra wrote: >> On Tue, Jan 17, 2017 at 02:03:03PM +0100, Michal Hocko wrote: >> > On Sun 15-01-17 20:19:01, Tejun Heo wrote: >> > [...] >> > > So, what's proposed is a proper part of bpf. In terms of >> >

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Tue 17-01-17 14:32:04, Peter Zijlstra wrote: > On Tue, Jan 17, 2017 at 02:03:03PM +0100, Michal Hocko wrote: > > On Sun 15-01-17 20:19:01, Tejun Heo wrote: > > [...] > > > So, what's proposed is a proper part of bpf. In terms of > > > implementation, cgroup helps by hosting the pointers but

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Tue 17-01-17 14:32:04, Peter Zijlstra wrote: > On Tue, Jan 17, 2017 at 02:03:03PM +0100, Michal Hocko wrote: > > On Sun 15-01-17 20:19:01, Tejun Heo wrote: > > [...] > > > So, what's proposed is a proper part of bpf. In terms of > > > implementation, cgroup helps by hosting the pointers but

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Tue, Jan 17, 2017 at 02:03:03PM +0100, Michal Hocko wrote: > On Sun 15-01-17 20:19:01, Tejun Heo wrote: > [...] > > So, what's proposed is a proper part of bpf. In terms of > > implementation, cgroup helps by hosting the pointers but that doesn't > > necessarily affect the conceptual structure

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Tue, Jan 17, 2017 at 02:03:03PM +0100, Michal Hocko wrote: > On Sun 15-01-17 20:19:01, Tejun Heo wrote: > [...] > > So, what's proposed is a proper part of bpf. In terms of > > implementation, cgroup helps by hosting the pointers but that doesn't > > necessarily affect the conceptual structure

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Sun 15-01-17 20:19:01, Tejun Heo wrote: [...] > So, what's proposed is a proper part of bpf. In terms of > implementation, cgroup helps by hosting the pointers but that doesn't > necessarily affect the conceptual structure of it. Given that, I > don't think it'd be a good idea to add anything

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Sun 15-01-17 20:19:01, Tejun Heo wrote: [...] > So, what's proposed is a proper part of bpf. In terms of > implementation, cgroup helps by hosting the pointers but that doesn't > necessarily affect the conceptual structure of it. Given that, I > don't think it'd be a good idea to add anything

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

Hello, Sorry about the delay. Some fire fighthing followed the holidays. On Tue, Jan 03, 2017 at 11:25:59AM +0100, Michal Hocko wrote: > > So from what I understand the proposed cgroup is not in fact > > hierarchical at all. > > > > @TJ, I thought you were enforcing all new cgroups to be

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

Hello, Sorry about the delay. Some fire fighthing followed the holidays. On Tue, Jan 03, 2017 at 11:25:59AM +0100, Michal Hocko wrote: > > So from what I understand the proposed cgroup is not in fact > > hierarchical at all. > > > > @TJ, I thought you were enforcing all new cgroups to be

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Tue 20-12-16 10:11:50, Peter Zijlstra wrote: > On Mon, Dec 19, 2016 at 05:56:24PM -0800, Andy Lutomirski wrote: > > >> 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

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Tue 20-12-16 10:11:50, Peter Zijlstra wrote: > On Mon, Dec 19, 2016 at 05:56:24PM -0800, Andy Lutomirski wrote: > > >> 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

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Tue, Dec 20, 2016 at 10:49:25AM -0800, Andy Lutomirski wrote: > >> FWIW, everywhere I say ioctl(), the bpf() syscall would be okay, too. > >> It doesn't make a semantic difference, except that I dislike > >> BPF_PROG_DETACH because that particular command isn't BPF-specific at > >> all. > > > >

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Tue, Dec 20, 2016 at 10:49:25AM -0800, Andy Lutomirski wrote: > >> FWIW, everywhere I say ioctl(), the bpf() syscall would be okay, too. > >> It doesn't make a semantic difference, except that I dislike > >> BPF_PROG_DETACH because that particular command isn't BPF-specific at > >> all. > > > >

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Tue, Dec 20, 2016 at 10:36 AM, Daniel Mack wrote: > Hi, > > On 12/20/2016 06:23 PM, Andy Lutomirski wrote: >> On Tue, Dec 20, 2016 at 2:21 AM, Daniel Mack wrote: > >> To clarify, since this thread has gotten excessively long and twisted, >> I think it's

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Tue, Dec 20, 2016 at 10:36 AM, Daniel Mack wrote: > Hi, > > On 12/20/2016 06:23 PM, Andy Lutomirski wrote: >> On Tue, Dec 20, 2016 at 2:21 AM, Daniel Mack wrote: > >> To clarify, since this thread has gotten excessively long and twisted, >> I think it's important that, for hooks attached to a

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

Hi, On 12/20/2016 06:23 PM, Andy Lutomirski wrote: > On Tue, Dec 20, 2016 at 2:21 AM, Daniel Mack wrote: > To clarify, since this thread has gotten excessively long and twisted, > I think it's important that, for hooks attached to a cgroup, you be > able to tell in a generic

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

Hi, On 12/20/2016 06:23 PM, Andy Lutomirski wrote: > On Tue, Dec 20, 2016 at 2:21 AM, Daniel Mack wrote: > To clarify, since this thread has gotten excessively long and twisted, > I think it's important that, for hooks attached to a cgroup, you be > able to tell in a generic way whether

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Tue, Dec 20, 2016 at 2:21 AM, Daniel Mack wrote: > Hi, > > On 12/20/2016 04:50 AM, Andy Lutomirski wrote: >> You mean BPF_CGROUP_RUN_PROG_INET_SOCK(sk)? There is nothing bpf >> specfic about the hook except that the name of this macro has "BPF" in >> it. There is nothing

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Tue, Dec 20, 2016 at 2:21 AM, Daniel Mack wrote: > Hi, > > On 12/20/2016 04:50 AM, Andy Lutomirski wrote: >> You mean BPF_CGROUP_RUN_PROG_INET_SOCK(sk)? There is nothing bpf >> specfic about the hook except that the name of this macro has "BPF" in >> it. There is nothing whatsoever that's

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

Hi, On 12/20/2016 04:50 AM, Andy Lutomirski wrote: > On Mon, Dec 19, 2016 at 7:18 PM, Alexei Starovoitov > wrote: >> On Mon, Dec 19, 2016 at 04:25:32PM -0800, Andy Lutomirski wrote: >>> I think we're still talking past each other. A big part of the point >>> of

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

Hi, On 12/20/2016 04:50 AM, Andy Lutomirski wrote: > On Mon, Dec 19, 2016 at 7:18 PM, Alexei Starovoitov > wrote: >> On Mon, Dec 19, 2016 at 04:25:32PM -0800, Andy Lutomirski wrote: >>> I think we're still talking past each other. A big part of the point >>> of changing it is that none of this

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 05:56:24PM -0800, Andy Lutomirski wrote: > >> 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

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 05:56:24PM -0800, Andy Lutomirski wrote: > >> 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

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 09:27:18PM -0800, Andy Lutomirski wrote: > On Mon, Dec 19, 2016 at 8:44 PM, Alexei Starovoitov > wrote: > > On Mon, Dec 19, 2016 at 07:12:48PM -0800, Andy Lutomirski wrote: > >> > >> struct cgroup_bpf { > >> /* > >> * Store

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 09:27:18PM -0800, Andy Lutomirski wrote: > On Mon, Dec 19, 2016 at 8:44 PM, Alexei Starovoitov > wrote: > > On Mon, Dec 19, 2016 at 07:12:48PM -0800, Andy Lutomirski wrote: > >> > >> struct cgroup_bpf { > >> /* > >> * Store two sets of bpf_prog pointers,

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 8:44 PM, Alexei Starovoitov wrote: > On Mon, Dec 19, 2016 at 07:12:48PM -0800, Andy Lutomirski wrote: >> >> struct cgroup_bpf { >> /* >> * Store two sets of bpf_prog pointers, one for programs that are >> * pinned

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 8:51 PM, Alexei Starovoitov wrote: > On Mon, Dec 19, 2016 at 05:40:53PM -0800, Andy Lutomirski wrote: >> >> By the way, even if Alexei is right, the BPF_PROG_DETACH API doesn't >> even take a reference to a BPF program as an argument. What is

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 8:44 PM, Alexei Starovoitov wrote: > On Mon, Dec 19, 2016 at 07:12:48PM -0800, Andy Lutomirski wrote: >> >> struct cgroup_bpf { >> /* >> * Store two sets of bpf_prog pointers, one for programs that are >> * pinned directly to this cgroup, and one

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 8:51 PM, Alexei Starovoitov wrote: > On Mon, Dec 19, 2016 at 05:40:53PM -0800, Andy Lutomirski wrote: >> >> By the way, even if Alexei is right, the BPF_PROG_DETACH API doesn't >> even take a reference to a BPF program as an argument. What is it >> supposed to do if this

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 05:40:53PM -0800, Andy Lutomirski wrote: > > By the way, even if Alexei is right, the BPF_PROG_DETACH API doesn't > even take a reference to a BPF program as an argument. What is it > supposed to do if this mechanism ever gets extended? we just add another field to that

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 05:40:53PM -0800, Andy Lutomirski wrote: > > By the way, even if Alexei is right, the BPF_PROG_DETACH API doesn't > even take a reference to a BPF program as an argument. What is it > supposed to do if this mechanism ever gets extended? we just add another field to that

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 07:50:01PM -0800, Andy Lutomirski wrote: > >> > >> net.socket_create_filter = "none": no filter > >> net.socket_create_filter = "bpf:baadf00d": bpf filter > > > > i'm assuming 'baadf00d' is bpf program fd expressed a text string? > > and kernel needs to parse above? will

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 07:50:01PM -0800, Andy Lutomirski wrote: > >> > >> net.socket_create_filter = "none": no filter > >> net.socket_create_filter = "bpf:baadf00d": bpf filter > > > > i'm assuming 'baadf00d' is bpf program fd expressed a text string? > > and kernel needs to parse above? will

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 07:12:48PM -0800, Andy Lutomirski wrote: > > struct cgroup_bpf { > /* > * Store two sets of bpf_prog pointers, one for programs that are > * pinned directly to this cgroup, and one for those that are > effective > * when this cgroup is

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 07:12:48PM -0800, Andy Lutomirski wrote: > > struct cgroup_bpf { > /* > * Store two sets of bpf_prog pointers, one for programs that are > * pinned directly to this cgroup, and one for those that are > effective > * when this cgroup is

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 7:18 PM, Alexei Starovoitov wrote: > On Mon, Dec 19, 2016 at 04:25:32PM -0800, Andy Lutomirski wrote: >> I think we're still talking past each other. A big part of the point >> of changing it is that none of this is specific to bpf. You

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 7:18 PM, Alexei Starovoitov wrote: > On Mon, Dec 19, 2016 at 04:25:32PM -0800, Andy Lutomirski wrote: >> I think we're still talking past each other. A big part of the point >> of changing it is that none of this is specific to bpf. You could (in > > the hooks and

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 04:25:32PM -0800, Andy Lutomirski wrote: > On Mon, Dec 19, 2016 at 4:02 PM, Alexei Starovoitov > wrote: > > On Mon, Dec 19, 2016 at 01:23:50PM -0800, Andy Lutomirski wrote: > >> On Mon, Dec 19, 2016 at 12:56 PM, Alexei Starovoitov > >>

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 04:25:32PM -0800, Andy Lutomirski wrote: > On Mon, Dec 19, 2016 at 4:02 PM, Alexei Starovoitov > wrote: > > On Mon, Dec 19, 2016 at 01:23:50PM -0800, Andy Lutomirski wrote: > >> On Mon, Dec 19, 2016 at 12:56 PM, Alexei Starovoitov > >> wrote: > >> > On Sat, Dec 17, 2016

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 6:52 PM, David Ahern wrote: > On 12/19/16 6:56 PM, Andy Lutomirski wrote: >> On Mon, Dec 19, 2016 at 5:44 PM, David Ahern wrote: >>> On 12/19/16 5:25 PM, Andy Lutomirski wrote: net.socket_create_filter = "none": no filter

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 6:52 PM, David Ahern wrote: > On 12/19/16 6:56 PM, Andy Lutomirski wrote: >> On Mon, Dec 19, 2016 at 5:44 PM, David Ahern wrote: >>> On 12/19/16 5:25 PM, Andy Lutomirski wrote: net.socket_create_filter = "none": no filter net.socket_create_filter =

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On 12/19/16 6:56 PM, Andy Lutomirski wrote: > On Mon, Dec 19, 2016 at 5:44 PM, David Ahern wrote: >> 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 >>>

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On 12/19/16 6:56 PM, Andy Lutomirski wrote: > On Mon, Dec 19, 2016 at 5:44 PM, David Ahern wrote: >> 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

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 5:44 PM, David Ahern wrote: > 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 >>

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 5:44 PM, David Ahern wrote: > 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 >>

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 4:25 PM, Andy Lutomirski wrote: > On Mon, Dec 19, 2016 at 4:02 PM, Alexei Starovoitov > wrote: >> you're ignoring use cases I described earlier. >> In vrf case there is only one ifindex it needs to bind to. > > I'm

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

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 >

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 4:25 PM, Andy Lutomirski wrote: > On Mon, Dec 19, 2016 at 4:02 PM, Alexei Starovoitov > wrote: >> 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

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

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 >

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 5:34 PM, David Miller wrote: > From: Alexei Starovoitov > Date: Mon, 19 Dec 2016 16:02:56 -0800 > >> huh? 'not right api' because it's using bpf syscall instead >> of cgroup control-file? I think the opposite is the

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 5:34 PM, David Miller wrote: > From: Alexei Starovoitov > Date: Mon, 19 Dec 2016 16:02:56 -0800 > >> huh? 'not right api' because it's using bpf syscall instead >> of cgroup control-file? I think the opposite is the truth. > > I completely agree with Alexei on this. So

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

From: Alexei Starovoitov Date: Mon, 19 Dec 2016 16:02:56 -0800 > huh? 'not right api' because it's using bpf syscall instead > of cgroup control-file? I think the opposite is the truth. I completely agree with Alexei on this.

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

From: Alexei Starovoitov Date: Mon, 19 Dec 2016 16:02:56 -0800 > huh? 'not right api' because it's using bpf syscall instead > of cgroup control-file? I think the opposite is the truth. I completely agree with Alexei on this.

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 4:02 PM, Alexei Starovoitov wrote: > On Mon, Dec 19, 2016 at 01:23:50PM -0800, Andy Lutomirski wrote: >> On Mon, Dec 19, 2016 at 12:56 PM, Alexei Starovoitov >> wrote: >> > On Sat, Dec 17, 2016 at 10:18:44AM

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 4:02 PM, Alexei Starovoitov wrote: > On Mon, Dec 19, 2016 at 01:23:50PM -0800, Andy Lutomirski wrote: >> On Mon, Dec 19, 2016 at 12:56 PM, Alexei Starovoitov >> wrote: >> > On Sat, Dec 17, 2016 at 10:18:44AM -0800, Andy Lutomirski wrote: >> >> Hi all- >> >> >> >> I

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 01:23:50PM -0800, Andy Lutomirski wrote: > On Mon, Dec 19, 2016 at 12:56 PM, Alexei Starovoitov > wrote: > > On Sat, Dec 17, 2016 at 10:18:44AM -0800, Andy Lutomirski wrote: > >> Hi all- > >> > >> I apologize for being rather late with this.

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 01:23:50PM -0800, Andy Lutomirski wrote: > On Mon, Dec 19, 2016 at 12:56 PM, Alexei Starovoitov > wrote: > > On Sat, Dec 17, 2016 at 10:18:44AM -0800, Andy Lutomirski wrote: > >> Hi all- > >> > >> I apologize for being rather late with this. I didn't realize that > >>

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 12:56 PM, Alexei Starovoitov wrote: > On Sat, Dec 17, 2016 at 10:18:44AM -0800, Andy Lutomirski wrote: >> Hi all- >> >> I apologize for being rather late with this. I didn't realize that >> cgroup-bpf was going to be submitted for Linux 4.10,

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 12:56 PM, Alexei Starovoitov wrote: > On Sat, Dec 17, 2016 at 10:18:44AM -0800, Andy Lutomirski wrote: >> Hi all- >> >> I apologize for being rather late with this. I didn't realize that >> cgroup-bpf was going to be submitted for Linux 4.10, and I didn't see >> it on the

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Sat, Dec 17, 2016 at 10:18:44AM -0800, Andy Lutomirski wrote: > Hi all- > > I apologize for being rather late with this. I didn't realize that > cgroup-bpf was going to be submitted for Linux 4.10, and I didn't see > it on the linux-api list, so I missed the discussion. > > I think that the

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Sat, Dec 17, 2016 at 10:18:44AM -0800, Andy Lutomirski wrote: > Hi all- > > I apologize for being rather late with this. I didn't realize that > cgroup-bpf was going to be submitted for Linux 4.10, and I didn't see > it on the linux-api list, so I missed the discussion. > > I think that the

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Sat, Dec 17, 2016 at 11:26 AM, Mickaël Salaün wrote: > > On 17/12/2016 19:18, Andy Lutomirski wrote: >> Hi all- >> >> I apologize for being rather late with this. I didn't realize that >> cgroup-bpf was going to be submitted for Linux 4.10, and I didn't see >> it on the

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Sat, Dec 17, 2016 at 11:26 AM, Mickaël Salaün wrote: > > On 17/12/2016 19:18, Andy Lutomirski wrote: >> Hi all- >> >> I apologize for being rather late with this. I didn't realize that >> cgroup-bpf was going to be submitted for Linux 4.10, and I didn't see >> it on the linux-api list, so I

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On 17/12/2016 19:18, Andy Lutomirski wrote: > Hi all- > > I apologize for being rather late with this. I didn't realize that > cgroup-bpf was going to be submitted for Linux 4.10, and I didn't see > it on the linux-api list, so I missed the discussion. > > I think that the inet ingress, egress

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On 17/12/2016 19:18, Andy Lutomirski wrote: > Hi all- > > I apologize for being rather late with this. I didn't realize that > cgroup-bpf was going to be submitted for Linux 4.10, and I didn't see > it on the linux-api list, so I missed the discussion. > > I think that the inet ingress, egress

Potential issues (security and otherwise) with the current cgroup-bpf API

Hi all- I apologize for being rather late with this. I didn't realize that cgroup-bpf was going to be submitted for Linux 4.10, and I didn't see it on the linux-api list, so I missed the discussion. I think that the inet ingress, egress etc filters are a neat feature, but I think the API has

Potential issues (security and otherwise) with the current cgroup-bpf API

Hi all- I apologize for being rather late with this. I didn't realize that cgroup-bpf was going to be submitted for Linux 4.10, and I didn't see it on the linux-api list, so I missed the discussion. I think that the inet ingress, egress etc filters are a neat feature, but I think the API has