All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Casey Schaufler <casey@schaufler-ca.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 0/3] Introduce CAP_BPF
Date: Fri, 8 May 2020 16:00:41 -0700	[thread overview]
Message-ID: <20200508230041.uwsj7ubk3zvphioe@ast-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <71f66e31-02d9-a661-af3b-f493140a53e2@schaufler-ca.com>

On Fri, May 08, 2020 at 03:45:36PM -0700, Casey Schaufler wrote:
> On 5/8/2020 2:53 PM, Alexei Starovoitov wrote:
> > From: Alexei Starovoitov <ast@kernel.org>
> >
> > v4->v5:
> >
> > Split BPF operations that are allowed under CAP_SYS_ADMIN into combination of
> > CAP_BPF, CAP_PERFMON, CAP_NET_ADMIN and keep some of them under CAP_SYS_ADMIN.
> >
> > The user process has to have
> > - CAP_BPF and CAP_PERFMON to load tracing programs.
> > - CAP_BPF and CAP_NET_ADMIN to load networking programs.
> > (or CAP_SYS_ADMIN for backward compatibility).
> 
> Is there a case where CAP_BPF is useful in the absence of other capabilities?
> I generally object to new capabilities in cases where existing capabilities
> are already required.

You mean beyond what is written about CAP_BPF in include/uapi/linux/capability.h in patch 1?
There are prog types that are neither tracing nor networking.
Like LIRC2 and cgroup-device are not, but they were put under CAP_SYS_ADMIN + CAP_NET_ADMIN
because there was no CAP_BPF. This patch keeps them under CAP_BPF + CAP_NET_ADMIN for now.
May be that can be relaxed later. For sure future prog types won't have to deal with
such binary decision.

      reply	other threads:[~2020-05-08 23:00 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
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 [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=20200508230041.uwsj7ubk3zvphioe@ast-mbp.dhcp.thefacebook.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=acme@redhat.com \
    --cc=bpf@vger.kernel.org \
    --cc=casey@schaufler-ca.com \
    --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.