On Sat, Apr 6, 2019 at 10:03 AM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Sat, Apr 06, 2019 at 09:43:50AM -0700, Kees Cook wrote: > > On Fri, Apr 5, 2019 at 12:36 PM Andrey Ignatov <rdna@xxxxxx> wrote: > > > BPF_CGROUP_SYSCTL hook is placed before calling to sysctl's proc_handler so > > > that accesses (read/write) to sysctl can be controlled for specific cgroup > > > and either allowed or denied, or traced. > > > > This sounds more like an LSM than BPF. > > not at all. the key difference is being cgroup scoped. > essentially for different containers. Okay, works for me. I was looking at it from the perspective of something providing resource access control policy, which usually falls into the LSM world. > bpf prog is attached to this hook in a particular cgroup > and executed for sysctls for tasks that belong to that cgroup. So it's root limiting root-in-a-container? Nice to have some boundaries there, for sure. > > Can the BPF be removed (or rather, > > what's the lifetime of such BPF?) > > same as all other cgroup-bpf hooks. > Do you have a specific concern or just asking how life time of programs > is managed? > High level description of lifetime is here: > https://facebookmicrosites.github.io/bpf/blog/2018/08/31/object-lifetime.html I'm mostly curious about the access control stacking. i.e. can in-container root add new eBPF to its own cgroup, and if so, can it undo the restrictions already present? (I assume it can't, but figured I'd ask...) -- Kees Cook
