lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 13 Mar 2020 19:58:32 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Lorenz Bauer <lmb@...udflare.com>
Cc:     Daniel Borkmann <daniel@...earbox.net>,
        kernel-team <kernel-team@...udflare.com>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        Jakub Sitnicki <jakub@...udflare.com>
Subject: Re: [PATCH 0/5] Return fds from privileged sockhash/sockmap lookup

On Fri, Mar 13, 2020 at 10:48:57AM +0000, Lorenz Bauer wrote:
> On Thu, 12 Mar 2020 at 17:58, Alexei Starovoitov
> <alexei.starovoitov@...il.com> 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?

It's different because it's crossing domains. FD_BY_ID returns FD for bpf
objects. Whereas here you're proposing bpf lookup to return FD from different
domain. If lookup was returning a socket cookie and separate api on the
networking side would convert cookie into FD I would be fine with that.

> > 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?

sure, but sockmap allows socket insertion. Hence it's part of considerations.

> 
> > 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?

I'm not following. There is skb->sk. Why do you need to lookup sk ? Because
your hook is before demux and skb->sk is not set? Then move your hook to after?

I think we're arguing in circles because in this thread I haven't seen the
explanation of the problem you're trying to solve. We argued about your
proposed solution and got stuck. Can we restart from the beginning with all
details?

Powered by blists - more mailing lists