On Tue, Jul 4, 2023, at 1:48 PM, Andy Lutomirski wrote:
> On Mon, Jun 26, 2023, at 8:23 AM, Daniel Borkmann wrote:
>> On 6/24/23 5:28 PM, Andy Lutomirski wrote:
>>
>> Wasn't this the idea of the BPF tokens proposal, meaning you could
>> create them with
>> restricted access as you mentioned - allowing an explicit subset of
>> program types to
>> be loaded, subset of helpers/kfuncs, map types, etc.. Given you pass in
>> this token
>> context upon program load-time (resp. map creation), the verifier is
>> then extended
>> for restricted access. For example, see the
>> bpf_token_allow_{cmd,map_type,prog_type}()
>> in this series. The user namespace relation was part of the use cases,
>> but not strictly
>> part of the mechanism itself in this series.
>
> Hmm. It's very coarse grained.
>
> Also, the bpf() attach API seems to be largely (completely?) missing
> what I would expect to be basic access controls on the things being
> attached to. For example, the whole cgroup_bpf_prog_attach() path
> seems to be entirely missing any checks as to whether its caller has
> any particular permission over the cgroup in question. It doesn't even
> check whether the cgroup is being accessed from the current userns
> (i.e. whether the fd refers to a struct file with f_path.mnt belonging
> to the current userns). So the API in this patchset has no way to
> restrict permission to attach to cgroups to only apply to cgroups
> belonging to the container.
>
Forgot to mention: there's also no way to limit the functions that can be called. While it's currently a bit of a pipe dream to do much useful work without bpf_probe_kernel_read(), it's at least conceptually possible to accomplish quite a bit without it, but there's no way to make that be part of the policy.
