Messages in this thread | | | From | Kees Cook <> | Date | Tue, 9 Apr 2019 09:50:50 -0700 | Subject | Re: [PATCH v3 bpf-next 00/21] bpf: Sysctl hook |
| |
On Sat, Apr 6, 2019 at 10:03 AM Alexei Starovoitov <alexei.starovoitov@gmail.com> 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@fb.com> 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
| |