All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Lorenz Bauer <lmb@cloudflare.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	kernel-team <kernel-team@cloudflare.com>,
	Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf v2 1/2] bpf: link: refuse non-O_RDWR flags in BPF_OBJ_GET
Date: Thu, 1 Apr 2021 14:44:15 -0700	[thread overview]
Message-ID: <CAADnVQJa0UX_64exKQ-k5GQKzQSCEnsL8uHYhKmck4sEXpeewQ@mail.gmail.com> (raw)
In-Reply-To: <CACAyw9_FHepkTzdFkiGUFV6F8u7zaZYOeH+bUjWxcBNBNeBYBg@mail.gmail.com>

On Wed, Mar 31, 2021 at 7:04 AM Lorenz Bauer <lmb@cloudflare.com> wrote:
>
> On Fri, 26 Mar 2021 at 16:05, Lorenz Bauer <lmb@cloudflare.com> wrote:
> >
> > Invoking BPF_OBJ_GET on a pinned bpf_link checks the path access
> > permissions based on file_flags, but the returned fd ignores flags.
> > This means that any user can acquire a "read-write" fd for a pinned
> > link with mode 0664 by invoking BPF_OBJ_GET with BPF_F_RDONLY in
> > file_flags. The fd can be used to invoke BPF_LINK_DETACH, etc.
> >
> > Fix this by refusing non-O_RDWR flags in BPF_OBJ_GET. This works
> > because OBJ_GET by default returns a read write mapping and libbpf
> > doesn't expose a way to override this behaviour for programs
> > and links.
>
> Hi Alexei and Daniel,
>
> I think these two patches might have fallen through the cracks, could
> you take a look? I'm not sure what the etiquette is around bumping a
> set, so please let me know if you'd prefer me to send the patches with
> acks included or something like that.

Applied both. Thanks

      parent reply	other threads:[~2021-04-01 21:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-26 16:05 [PATCH bpf v2 1/2] bpf: link: refuse non-O_RDWR flags in BPF_OBJ_GET Lorenz Bauer
2021-03-26 16:05 ` [PATCH bpf v2 2/2] bpf: program: " Lorenz Bauer
2021-03-26 20:13   ` Song Liu
2021-03-28  4:51     ` Andrii Nakryiko
2021-03-29  8:19     ` Lorenz Bauer
2021-03-28  4:49 ` [PATCH bpf v2 1/2] bpf: link: " Andrii Nakryiko
2021-03-31 14:04 ` Lorenz Bauer
2021-04-01 18:04   ` Alexei Starovoitov
2021-04-01 21:44   ` Alexei Starovoitov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAADnVQJa0UX_64exKQ-k5GQKzQSCEnsL8uHYhKmck4sEXpeewQ@mail.gmail.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kernel-team@cloudflare.com \
    --cc=lmb@cloudflare.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.