netdev - Re: [PATCH v5 bpf-next 0/3] Introduce CAP

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: <20200508230041.uwsj7ubk3zvphioe@ast-mbp.dhcp.thefacebook.com>
Date:   Fri, 8 May 2020 16:00:41 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Casey Schaufler <casey@...aufler-ca.com>
Cc:     davem@...emloft.net, daniel@...earbox.net, netdev@...r.kernel.org,
        bpf@...r.kernel.org, kernel-team@...com,
        linux-security-module@...r.kernel.org, acme@...hat.com,
        jamorris@...ux.microsoft.com, jannh@...gle.com, kpsingh@...gle.com
Subject: Re: [PATCH v5 bpf-next 0/3] Introduce CAP_BPF

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@...nel.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.