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: <CAEf4BzZ2-a+m_wV2sffKMQ1Zi7wREvV=mkBmQC4ExQsi9zpbww@mail.gmail.com>
Date:   Mon, 30 Mar 2020 18:06:14 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     Andrey Ignatov <rdna@...com>, Andrii Nakryiko <andriin@...com>,
        bpf <bpf@...r.kernel.org>, Networking <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Kernel Team <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 5:38 PM Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
>
> 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.

Thanks!

>
> > This is pretty importnant difference but I don't see it clarified in the
> > commit message or discussed (or I missed it?).

Yeah, not intentional, thanks for catching!

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ