netdev - Re: [PATCH v3 bpf-next 1/4] bpf: implement bpf_link-based cgroup BPF program attachment

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: <20200331003833.2cimhnn5scfroyv7@ast-mbp>
Date:   Mon, 30 Mar 2020 17:38:33 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Andrey Ignatov <rdna@...com>
Cc:     Andrii Nakryiko <andriin@...com>, bpf@...r.kernel.org,
        netdev@...r.kernel.org, ast@...com, daniel@...earbox.net,
        andrii.nakryiko@...il.com, kernel-team@...com
Subject: Re: [PATCH v3 bpf-next 1/4] bpf: implement bpf_link-based cgroup BPF
 program attachment

On Mon, Mar 30, 2020 at 05:05:13PM -0700, Andrey Ignatov wrote:
> >  
> > +#define BPF_LINK_CREATE_LAST_FIELD link_create.flags
> > +static int link_create(union bpf_attr *attr)
> > +{
> 
> From what I see this function does not check any capability whether the
> existing bpf_prog_attach() checks for CAP_NET_ADMIN.

Great catch! It's a bug.
I fixed it up.

> This is pretty importnant difference but I don't see it clarified in the
> commit message or discussed (or I missed it?).
> 
> Having a way to attach cgroup bpf prog by non-priv users is actually
> helpful in some use-cases, e.g. systemd required patching in the past to
> make it work with user (non-priv) sessions, see [0].
> 
> But in other cases it's also useful to limit the ability to attach
> programs to a cgroup while using bpf_link so that only the thing that
> controls cgroup setup can attach but not any non-priv process running in
> that cgroup. How is this use-case covered in BPF_LINK_CREATE?
> 
> 
> [0] https://github.com/systemd/systemd/pull/12745

yeah. we need to resurrect the discussion around CAP_BPF.

PS
pls trim your replies.