All of lore.kernel.org
 help / color / mirror / Atom feed
From: sdf@google.com
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: davem@davemloft.net, daniel@iogearbox.net,
	netdev@vger.kernel.org, bpf@vger.kernel.org, kernel-team@fb.com,
	linux-security-module@vger.kernel.org, acme@redhat.com,
	jamorris@linux.microsoft.com, jannh@google.com,
	kpsingh@google.com
Subject: Re: [PATCH v5 bpf-next 2/3] bpf: implement CAP_BPF
Date: Mon, 11 May 2020 17:12:10 -0700	[thread overview]
Message-ID: <20200512001210.GA235661@google.com> (raw)
In-Reply-To: <20200508215340.41921-3-alexei.starovoitov@gmail.com>

On 05/08, Alexei Starovoitov wrote:
> From: Alexei Starovoitov <ast@kernel.org>
[..]
> @@ -3932,7 +3977,7 @@ SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr  
> __user *, uattr, unsigned int, siz
>   	union bpf_attr attr;
>   	int err;

> -	if (sysctl_unprivileged_bpf_disabled && !capable(CAP_SYS_ADMIN))
> +	if (sysctl_unprivileged_bpf_disabled && !bpf_capable())
>   		return -EPERM;
This is awesome, thanks for reviving the effort!

One question I have about this particular snippet:
Does it make sense to drop bpf_capable checks for the operations
that work on a provided fd?

The use-case I have in mind is as follows:
* privileged (CAP_BPF) process loads the programs/maps and pins
   them at some known location
* unprivileged process opens up those pins and does the following:
   * prepares the maps (and will later on read them)
   * does SO_ATTACH_BPF/SO_ATTACH_REUSEPORT_EBPF which afaik don't
     require any capabilities

This essentially pushes some of the permission checks into a fs layer. So
whoever has a file descriptor (via unix sock or open) can do BPF operations
on the object that represents it.

Thoughts? Am I missing something important?

  reply	other threads:[~2020-05-12  0:12 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-08 21:53 [PATCH v5 bpf-next 0/3] Introduce CAP_BPF Alexei Starovoitov
2020-05-08 21:53 ` [PATCH v5 bpf-next 1/3] bpf, capability: " Alexei Starovoitov
2020-05-08 21:53 ` [PATCH v5 bpf-next 2/3] bpf: implement CAP_BPF Alexei Starovoitov
2020-05-12  0:12   ` sdf [this message]
2020-05-12  2:36     ` Alexei Starovoitov
2020-05-12 12:50       ` Jordan Glover
2020-05-12 15:46         ` Alexei Starovoitov
2020-05-12 15:54       ` sdf
2020-05-12 18:39         ` Alexei Starovoitov
2020-05-12 14:35   ` Daniel Borkmann
2020-05-12 18:25     ` Alexei Starovoitov
2020-05-12 20:07       ` Daniel Borkmann
2020-05-12 22:56         ` Alexei Starovoitov
2020-05-12 15:05   ` Daniel Borkmann
2020-05-12 18:29     ` Alexei Starovoitov
2020-05-12 20:09       ` Daniel Borkmann
2020-05-12 20:27   ` Daniel Borkmann
2020-05-12 23:01     ` Alexei Starovoitov
2020-05-08 21:53 ` [PATCH v5 bpf-next 3/3] selftests/bpf: use CAP_BPF and CAP_PERFMON in tests Alexei Starovoitov
2020-05-08 22:45 ` [PATCH v5 bpf-next 0/3] Introduce CAP_BPF Casey Schaufler
2020-05-08 23:00   ` Alexei Starovoitov

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=20200512001210.GA235661@google.com \
    --to=sdf@google.com \
    --cc=acme@redhat.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=jamorris@linux.microsoft.com \
    --cc=jannh@google.com \
    --cc=kernel-team@fb.com \
    --cc=kpsingh@google.com \
    --cc=linux-security-module@vger.kernel.org \
    --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.