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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <59e56064-354c-d6b9-101a-c698976e6723@fb.com>
Date:   Tue, 25 Jun 2019 21:00:10 +0000
From:   Alexei Starovoitov <ast@...com>
To:     Stanislav Fomichev <sdf@...ichev.me>,
        Song Liu <songliubraving@...com>
CC:     "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 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?