Re: [PATCH 0/5] Return fds from privileged sockhash/sockmap lookup

On Thu, 12 Mar 2020 at 17:58, Alexei Starovoitov
[off-list ref] wrote:

but there it goes through ptrace checks and lsm hoooks, whereas here similar
security model cannot be enforced. bpf prog can put any socket into sockmap and
from bpf_lookup_elem side there is no way to figure out the owner task of the
socket to do ptrace checks. Just doing it all under CAP_NET_ADMIN is not a
great security answer.

Reading between the lines, you're concerned about something like a sock ops
program "stealing" the socket and putting it in a sockmap, to be retrieved by an
attacker later on?

How is that different than BPF_MAP_GET_FD_BY_ID, except that it's CAP_SYS_ADMIN?

but bpf side may still need to insert them into old.
you gonna solve it with a flag for the prog to stop doing its job?
Or the prog will know that it needs to put sockets into second map now?
It's really the same problem as with classic so_reuseport
which was solved with BPF_MAP_TYPE_REUSEPORT_SOCKARRAY.

We don't modify the sockmap from eBPF:
   receive a packet -> lookup sk in sockmap based on packet -> redirect

Why do you think we'll have to insert sockets from BPF?

I think sockmap needs a redesign. Consider that today all sockets can be in any
number of sk_local_storage pseudo maps. They are 'defragmented' and resizable.
I think plugging socket redirect to use sk_local_storage-like infra is the
answer.

Maybe Jakub can speak more to this but I don't see how this solves our problem.
We need a way to get at struct sk * from an eBPF program that runs on
an skb context,
to make BPF socket dispatch feasible. How would we use
sk_local_storage if we don't
have a sk?

-- 
Lorenz Bauer  |  Systems Engineer
6th Floor, County Hall/The Riverside Building, SE1 7PB, UK

www.cloudflare.com