Re: Debugging eBPF was: Re: [PATCH bpf-next 0/8] tools: bpftool: add probes for system and device

Em Thu, Dec 13, 2018 at 12:55:10PM -0800, Alexei Starovoitov escreveu:

On Thu, Dec 13, 2018 at 10:49:09AM -0300, Arnaldo Carvalho de Melo wrote:

quoted

Only root can attach eBPF programs to tracepoints.

quoted

Would be really good if we could have a more restricted program type to
attach to tracepoints, one that would be able to run only in the context
of their threads and access only the pointers in the tracepoints, that
way the 'perf trace' augmented syscalls code would be usable for
non-root users just like the other 'perf' commands are, allowing us to,
as with root, to copy the pointer arguments, like:

I don't think there is a clean way of doing non-root with tracepoints or syscalls.
The kernel side would need to start filtering the progs.
Like current uid == uid of loaded prog. But then there are tail_calls.

Yeah, that program would run only for threads owned by the prog owner.

they would need to be disabled. 

I think if that is not possible, then would be an acceptable limitation
in a first implementation. I.e. my understanding is that eBPF started
with some limited scope, then as it goes maturing, more features were
added as its security/performance implications were understood.

tracepoints args can be pointers. _all_ of them in the kernel would need to
be annotated to make sure pointers don't leak into unpriv user space.
and so on and so forth.

Yes, I thought about heavily restricting them, i.e. points would be
allowed just for some very special cases, like the arguments to
raw_syscalls.sys_{sys_enter,sys_exit}, as a starting point.
 

I think better way forward would be to introduce something in the middle.
Between root and unpriv. Something that tracing bpf progs can use.
May be new capability?

Well, that would be interesting too, I think, would make go a bit
forward, for a class of applications where trusting the tracer is
possible.

- Arnaldo