On Sat, Jul 8, 2023 at 1:59 AM Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> 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!
