netdev - Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf

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]

Date:   Fri, 2 Aug 2019 07:21:33 +0000
From:   Song Liu <songliubraving@...com>
To:     Andy Lutomirski <luto@...nel.org>
CC:     Kees Cook <keescook@...omium.org>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        "Daniel Borkmann" <daniel@...earbox.net>,
        Kernel Team <Kernel-team@...com>,
        "Lorenz Bauer" <lmb@...udflare.com>, Jann Horn <jannh@...gle.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Linux API <linux-api@...r.kernel.org>,
        LSM List <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf

Hi Andy,

> On Jul 31, 2019, at 12:09 PM, Andy Lutomirski <luto@...nel.org> wrote:
> 
> On Wed, Jul 31, 2019 at 1:10 AM Song Liu <songliubraving@...com> wrote:
>> 
>> 
>> 
>>> On Jul 30, 2019, at 1:24 PM, Andy Lutomirski <luto@...nel.org> wrote:
>>> 
>>> On Mon, Jul 29, 2019 at 10:07 PM Song Liu <songliubraving@...com> wrote:
>>>> 
>>>> Hi Andy,
>>>> 
>>>>> On Jul 27, 2019, at 11:20 AM, Song Liu <songliubraving@...com> wrote:
>>>>> 
>>>>> Hi Andy,
>>>>> 
>>>>> 
>> 
>> [...]
>> 
>>>>> 
>>>> 
>>>> I would like more comments on this.
>>>> 
>>>> Currently, bpf permission is more or less "root or nothing", which we
>>>> would like to change.
>>>> 
>>>> The short term goal is to separate bpf from root, in other words, it is
>>>> "all or nothing". Special user space utilities, such as systemd, would
>>>> benefit from this. Once this is implemented, systemd can call sys_bpf()
>>>> when it is not running as root.
>>> 
>>> As generally nasty as Linux capabilities are, this sounds like a good
>>> use for CAP_BPF_ADMIN.
>> 
>> I actually agree CAP_BPF_ADMIN makes sense. The hard part is to make
>> existing tools (setcap, getcap, etc.) and libraries aware of the new CAP.
> 
> It's been done before -- it's not that hard.  IMO the main tricky bit
> would be try be somewhat careful about defining exactly what
> CAP_BPF_ADMIN does.

Agreed. I think defining CAP_BPF_ADMIN could be a good topic for the 
Plumbers conference. 

OTOH, I don't think we have to wait for CAP_BPF_ADMIN to allow daemons 
like systemd to do sys_bpf() without root. 

> 
>>> I don't see why you need to invent a whole new mechanism for this.
>>> The entire cgroup ecosystem outside bpf() does just fine using the
>>> write permission on files in cgroupfs to control access.  Why can't
>>> bpf() do the same thing?
>> 
>> It is easier to use write permission for BPF_PROG_ATTACH. But it is
>> not easy to do the same for other bpf commands: BPF_PROG_LOAD and
>> BPF_MAP_*. A lot of these commands don't have target concept. Maybe
>> we should have target concept for all these commands. But that is a
>> much bigger project. OTOH, "all or nothing" model allows all these
>> commands at once.
> 
> For BPF_PROG_LOAD, I admit I've never understood why permission is
> required at all.  I think that CAP_SYS_ADMIN or similar should be
> needed to get is_priv in the verifier, but I think that should mainly
> be useful for tracing, and that requires lots of privilege anyway.
> BPF_MAP_* is probably the trickiest part.  One solution would be some
> kind of bpffs, but I'm sure other solutions are possible.

Improving permission management of cgroup_bpf is another good topic to
discuss. However, it is also an overkill for current use case. 

Let me get more details about the use case, so that we have a clear 
picture about short term and long term goals. 

Thanks again for your suggestions. 
Song