netdev - Re: [PATCH bpf-next 0/4] sys_bpf() access control 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]

Message-ID: <40059e14-7ce0-3d32-8092-698f72612ff3@fb.com>
Date:   Tue, 25 Jun 2019 22:47:58 +0000
From:   Alexei Starovoitov <ast@...com>
To:     Stanislav Fomichev <sdf@...ichev.me>
CC:     Song Liu <songliubraving@...com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        "ast@...nel.org" <ast@...nel.org>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        Kernel Team <Kernel-team@...com>
Subject: Re: [PATCH bpf-next 0/4] sys_bpf() access control via /dev/bpf

On 6/25/19 2:19 PM, Stanislav Fomichev wrote:
> On 06/25, Alexei Starovoitov wrote:
>> On 6/25/19 1:51 PM, Stanislav Fomichev wrote:
>>> On 06/25, Song Liu wrote:
>>>> Currently, most access to sys_bpf() is limited to root. However, there are
>>>> use cases that would benefit from non-privileged use of sys_bpf(), e.g.
>>>> systemd.
>>>>
>>>> This set introduces a new model to control the access to sys_bpf(). A
>>>> special device, /dev/bpf, is introduced to manage access to sys_bpf().
>>>> Users with access to open /dev/bpf will be able to access most of
>>>> sys_bpf() features. The use can get access to sys_bpf() by opening /dev/bpf
>>>> and use ioctl to get/put permission.
>>>>
>>>> The permission to access sys_bpf() is marked by bit TASK_BPF_FLAG_PERMITTED
>>>> in task_struct. During fork(), child will not inherit this bit.
>>> 2c: if we are going to have an fd, I'd vote for a proper fd based access
>>> checks instead of a per-task flag, so we can do:
>>> 	ioctl(fd, BPF_MAP_CREATE, uattr, sizeof(uattr))
>>>
>>> (and pass this fd around)
>>>
>>> I do understand that it breaks current assumptions that libbpf has,
>>> but maybe we can extend _xattr variants to accept optinal fd (and try
>>> to fallback to sysctl if it's absent/not working)?
>>
>> both of these ideas were discussed at lsfmm where you were present.
>> I'm not sure why you're bring it up again?
> Did we actually settle on anything? In that case feel free to ignore me,
> maybe I missed that. I remember there were pros/cons for both implementations.

yes. That was my understanding from lsfmm.
Which was:
1. replicating all commands via ioctl is not going to work.
   Also ioctl cannot return fd.
2. adding fd to all structs inside bpf_attr is a big churn on uapi.
   all future structs would need to have this extra fd as well.
   I don't like that kind of crutch to be carried over and over again.

The only thing we can consider instead of ioctl is to add single
new command for bpf syscall that will take that fd and apply
the attribute to task struct.
ioctl on that fd or new command look equivalent to me.