Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-08 Thread Ingo Molnar
* Alexei Starovoitov wrote: > As far as sysctl we can look at two with similar purpose: > sysctl_perf_event_paranoid and modules_disabled. > First one is indeed multi level, but not because of the fear of bugs, > but because of real security implications. It serves both

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-08 Thread Alexei Starovoitov
On 10/7/15 11:21 PM, Ingo Molnar wrote: so I see no reason why unprivileged eBPF couldn't have a sysctl too - with the default value set to permissive. agreed. sent out v2 follows 'modules_disabled' style. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-08 Thread Kees Cook
On Wed, Oct 7, 2015 at 4:49 PM, Alexei Starovoitov wrote: > On 10/7/15 3:22 PM, Kees Cook wrote: >>> >>> Yes, I agree with you that there would be a CVE regardless. I still >>> >like the option of configurable access, not a big fan of the sysctl >>> >either. Thinking out

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-07 Thread Alexei Starovoitov
On 10/6/15 5:45 AM, Daniel Borkmann wrote: Should instead something similar be adapted on bpf(2) as well? Or, would that even be more painful for application developers shipping their stuff through distros in the end (where they might then decide to just setup everything BPF-related and then

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-07 Thread Kees Cook
On Wed, Oct 7, 2015 at 3:07 PM, Daniel Borkmann wrote: > On 10/07/2015 11:20 PM, Alexei Starovoitov wrote: >> >> On 10/6/15 5:45 AM, Daniel Borkmann wrote: >>> >>> Should instead something similar be adapted on bpf(2) as well? Or, would >>> that even be more painful for

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-07 Thread Daniel Borkmann
On 10/07/2015 11:20 PM, Alexei Starovoitov wrote: On 10/6/15 5:45 AM, Daniel Borkmann wrote: Should instead something similar be adapted on bpf(2) as well? Or, would that even be more painful for application developers shipping their stuff through distros in the end (where they might then

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-07 Thread Ingo Molnar
* Andy Lutomirski wrote: > On Tue, Oct 6, 2015 at 10:56 AM, Eric Dumazet wrote: > > On Tue, 2015-10-06 at 10:50 -0700, Alexei Starovoitov wrote: > > > >> was also thinking that we can do it only in paths that actually > >> have multiple protocol

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-07 Thread Alexei Starovoitov
On 10/7/15 3:22 PM, Kees Cook wrote: Yes, I agree with you that there would be a CVE regardless. I still >like the option of configurable access, not a big fan of the sysctl >either. Thinking out loudly, what about a Kconfig option? We started >out like this on bpf(2) itself (initially under

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-07 Thread Alexei Starovoitov
On 10/5/15 1:48 PM, Alexei Starovoitov wrote: Unprivileged socket filter bpf programs have access to the following helper functions: - map lookup/update/delete (but they cannot store kernel pointers into them) - get_random (it's already exposed to unprivileged user space) - get_smp_processor_id

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-06 Thread Alexei Starovoitov
On 10/6/15 1:39 AM, Daniel Borkmann wrote: [...] Also classic BPF would then need to test for it, since a socket filter doesn't really know whether native eBPF is loaded there or a classic-to-eBPF transformed one, and classic never makes use of this. Anyway, it could be done by adding a bit flag

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-06 Thread Daniel Borkmann
On 10/06/2015 07:50 PM, Alexei Starovoitov wrote: On 10/6/15 1:39 AM, Daniel Borkmann wrote: [...] Also classic BPF would then need to test for it, since a socket filter doesn't really know whether native eBPF is loaded there or a classic-to-eBPF transformed one, and classic never makes use of

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-06 Thread Alexei Starovoitov
On 10/6/15 10:56 AM, Eric Dumazet wrote: On Tue, 2015-10-06 at 10:50 -0700, Alexei Starovoitov wrote: was also thinking that we can do it only in paths that actually have multiple protocol layers, since today bpf is mainly used with tcpdump(raw_socket) and new af_packet fanout both have cb

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-06 Thread Andy Lutomirski
On Tue, Oct 6, 2015 at 10:56 AM, Eric Dumazet wrote: > On Tue, 2015-10-06 at 10:50 -0700, Alexei Starovoitov wrote: > >> was also thinking that we can do it only in paths that actually >> have multiple protocol layers, since today bpf is mainly used with >>

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-06 Thread Eric Dumazet
On Tue, 2015-10-06 at 10:50 -0700, Alexei Starovoitov wrote: > was also thinking that we can do it only in paths that actually > have multiple protocol layers, since today bpf is mainly used with > tcpdump(raw_socket) and new af_packet fanout both have cb cleared > on RX, because it just came out

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-06 Thread Ingo Molnar
* Alexei Starovoitov wrote: > On 10/5/15 3:14 PM, Daniel Borkmann wrote: > >One scenario that comes to mind ... what happens when there are kernel > >pointers stored in skb->cb[] (either from the current layer or an old > >one from a different layer that the skb went through

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-06 Thread Ingo Molnar
* Daniel Borkmann wrote: > On 10/06/2015 09:13 AM, Ingo Molnar wrote: > > > >* Alexei Starovoitov wrote: > > > >>On 10/5/15 3:14 PM, Daniel Borkmann wrote: > >>>One scenario that comes to mind ... what happens when there are kernel > >>>pointers stored

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-06 Thread Daniel Borkmann
On 10/06/2015 10:20 AM, Ingo Molnar wrote: * Daniel Borkmann wrote: On 10/06/2015 09:13 AM, Ingo Molnar wrote: * Alexei Starovoitov wrote: On 10/5/15 3:14 PM, Daniel Borkmann wrote: One scenario that comes to mind ... what happens when there are

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-06 Thread Daniel Borkmann
On 10/06/2015 09:13 AM, Ingo Molnar wrote: * Alexei Starovoitov wrote: On 10/5/15 3:14 PM, Daniel Borkmann wrote: One scenario that comes to mind ... what happens when there are kernel pointers stored in skb->cb[] (either from the current layer or an old one from a

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-06 Thread Daniel Borkmann
On 10/06/2015 02:51 AM, Alexei Starovoitov wrote: On 10/5/15 3:14 PM, Daniel Borkmann wrote: One scenario that comes to mind ... what happens when there are kernel pointers stored in skb->cb[] (either from the current layer or an old one from a different layer that the skb went through

[PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-05 Thread Alexei Starovoitov
In order to let unprivileged users load and execute eBPF programs teach verifier to prevent pointer leaks. Verifier will prevent - any arithmetic on pointers (except R10+Imm which is used to compute stack addresses) - comparison of pointers - passing pointers to helper functions - indirectly

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-05 Thread Kees Cook
On Mon, Oct 5, 2015 at 1:48 PM, Alexei Starovoitov wrote: > In order to let unprivileged users load and execute eBPF programs > teach verifier to prevent pointer leaks. > Verifier will prevent > - any arithmetic on pointers > (except R10+Imm which is used to compute stack

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-05 Thread Alexei Starovoitov
On 10/5/15 3:14 PM, Daniel Borkmann wrote: One scenario that comes to mind ... what happens when there are kernel pointers stored in skb->cb[] (either from the current layer or an old one from a different layer that the skb went through previously, but which did not get overwritten)? Socket

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-05 Thread Alexei Starovoitov
On 10/5/15 2:00 PM, Kees Cook wrote: On Mon, Oct 5, 2015 at 1:48 PM, Alexei Starovoitov wrote: >In order to let unprivileged users load and execute eBPF programs >teach verifier to prevent pointer leaks. >Verifier will prevent >- any arithmetic on pointers > (except

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-05 Thread Alexei Starovoitov
On 10/5/15 2:16 PM, Andy Lutomirski wrote: On Mon, Oct 5, 2015 at 2:12 PM, Alexei Starovoitov wrote: On 10/5/15 2:00 PM, Kees Cook wrote: On Mon, Oct 5, 2015 at 1:48 PM, Alexei Starovoitov wrote: In order to let unprivileged users load and execute

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-05 Thread Kees Cook
On Mon, Oct 5, 2015 at 2:12 PM, Alexei Starovoitov wrote: > On 10/5/15 2:00 PM, Kees Cook wrote: >> >> On Mon, Oct 5, 2015 at 1:48 PM, Alexei Starovoitov >> wrote: >>> >>> >In order to let unprivileged users load and execute eBPF programs >>> >teach verifier

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-05 Thread Daniel Borkmann
On 10/05/2015 10:48 PM, Alexei Starovoitov wrote: In order to let unprivileged users load and execute eBPF programs teach verifier to prevent pointer leaks. Verifier will prevent - any arithmetic on pointers (except R10+Imm which is used to compute stack addresses) - comparison of pointers -

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-05 Thread Andy Lutomirski
On Mon, Oct 5, 2015 at 2:12 PM, Alexei Starovoitov wrote: > On 10/5/15 2:00 PM, Kees Cook wrote: >> >> On Mon, Oct 5, 2015 at 1:48 PM, Alexei Starovoitov >> wrote: >>> >>> >In order to let unprivileged users load and execute eBPF programs >>> >teach verifier

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

2015-10-05 Thread Alexei Starovoitov
On 10/5/15 3:02 PM, Kees Cook wrote: the array maps that hold FDs (BPF_MAP_TYPE_PROG_ARRAY and >BPF_MAP_TYPE_PERF_EVENT_ARRAY) don't have lookup/update accessors >from the program side, so programs cannot see or manipulate >those pointers. >For the former only bpf_tail_call() is allowed that