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

* Andy Lutomirski [off-list ref] wrote:

On Tue, Oct 6, 2015 at 10:56 AM, Eric Dumazet [off-list ref] wrote:

quoted

On Tue, 2015-10-06 at 10:50 -0700, Alexei Starovoitov wrote:

quoted

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 of alloc_skb and no layers were called,
and on TX we can clear 20 bytes in dev_queue_xmit_nit().
af_unix/netlink also have clean skb. Need to analyze tun and sctp...
but it feels overly fragile to save a branch in sk_filter,
so planning to go with
if(unlikely(prog->cb_access)) memset in sk_filter().

This will break TCP use of sk_filter().
skb->cb[] contains useful data in TCP layer.

Since I don't know too much about the networking details:

1. Does "skb->cb" *ever* contain anything useful for an unprivileged user?

2. Does sbk->cb form a stable ABI?

Unless both answers are solid yesses, then maybe the right solution is
to just deny access entirely to unprivileged users.

So this kind of instrumentation data is not an ABI in a similar fashion as tracing 
information is not an ABI either.

I.e. tracepoints can (and sometimes do) change 'semantics' - in that the 
interpretation of the implementational details behind that data changes as the 
implementation changes. That's not something that can ever be an ABI, just like 
the contents of /proc/kcore or /proc/slabinfo can not be an ABI.

Thanks,

	Ingo