netdev - Re: [PATCH bpf-next 1/4] xdp: Support specifying expected existing program when attaching XDP

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 linux-cve-announce 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]

Message-ID: <20200331034319.lg2tgxxs5eyiqebi@ast-mbp>
Date:   Mon, 30 Mar 2020 20:43:19 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Edward Cree <ecree@...arflare.com>
Cc:     David Ahern <dsahern@...il.com>, Lorenz Bauer <lmb@...udflare.com>,
        Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        John Fastabend <john.fastabend@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Andrii Nakryiko <andriin@...com>,
        "David S. Miller" <davem@...emloft.net>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Andrey Ignatov <rdna@...com>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH bpf-next 1/4] xdp: Support specifying expected existing
 program when attaching XDP

On Mon, Mar 30, 2020 at 04:25:07PM +0100, Edward Cree wrote:
> On 27/03/2020 23:02, Alexei Starovoitov wrote:
> > On Fri, Mar 27, 2020 at 10:12:05AM -0600, David Ahern wrote:
> >> I had a thought yesterday along similar lines: bpf_link is about
> >> ownership and preventing "accidental" deletes.
> > The mechanism for "human override" is tbd.
> Then that's a question you really need to solve, especially if you're
>  going to push bpf_link quite so... forcefully.
> Everything that a human operator can do, so can any program with the
>  same capabilities/wheel bits.  Especially as the API that the
>  operator-tool uses *will* be open and documented.  The Unix Way does
>  not allow unscriptable interfaces, and heavily frowns at any kind of
>  distinction between 'humans' and 'programs'.

can you share a link on such philosophy?
I was thinking something like CAPTCHA 'confirm if you're not a robot'
type of a button.
So humans doing 'bpftool link show' followed by 'bpftool link del id 123'
will work as expected, but processes cannot use the same api to
nuke other processes.

> So what will the override look like?  A bpf() syscall with a special
>  BPF_F_IM_A_HUMAN_AND_I_KNOW_WHAT_IM_DOING flag?  ptracing the link
>  owner, so that you can close() its fd?  Something in between?

not sure yet.

> In any case, the question is orthogonal to the bpf_link vs. netlink
>  issue: the netlink XDP attach could be done with a flag that means
>  "don't allow replacement/removal without EXPECTED_FD".  No?

Nothing to do with netlink, of course. Both XDP and tc bpf hooks
missing the concept of owner of the attachment.
For tc it's easier to implement and understand, since it allows
multi prog. If process A attaches a tc clsbpf prog via bpf_link
another process B will not be able to nuke it.