[PATCH RESEND v3 bpf-next 01/14] bpf: introduce BPF token object

[Djalal Harouni]

On Sat, Jul 8, 2023 at 1:59 AM Andrii Nakryiko
<andrii.nakryiko at gmail.com> wrote:
>
...
> > >
> > > Why can't distro disable this in some more dynamic way, though? With
> > > existing LSM mechanism, sysctl, whatever? I think it would be useful
> > > to let users have control over this and decide for themselves without
> > > having to rebuild a custom kernel.
> >
> > A sysctl similar to the existing one for unprivileged BPF would be fine
> > as well. If an LSM ends up being the only way to control it, though,
> > that will carry so much operational overhead for us to get to a working
> > state that it'll most likely be simpler to just patch it out of the
> > kernel.
>
> Sounds good, I will add sysctl for the next version.

What would be the purpose of the sysctl? or a kconfig? AFAICT the
operation is still privileged, and it's an opt-in? anyway...

It is obvious that this should be part of the BPF core... The other
user space proxy solution tries to solve another use case competing
with LSMs. It won't be able to handle the full context (or today's
nested workload) at bpf() call time... There are obvious reasons why
LSMs do exist...

Thanks for agreeing that it should be attached to the user namespace
at creation time as it is crucial to get it right... and Christian
(thanks BTW ;-) ) maybe we make it walk user ns list up to parent and
allow the token if it's coming from a parent namespace that is part of
the same hierarchy, then theoretically the parent ns is more
privileged...  will check again and reply to the corresponding email.

Thanks!