On Sat, Apr 6, 2019 at 10:03 AM Alexei Starovoitov
[off-list ref] wrote:

On Sat, Apr 06, 2019 at 09:43:50AM -0700, Kees Cook wrote:

quoted

On Fri, Apr 5, 2019 at 12:36 PM Andrey Ignatov [off-list ref] wrote:

quoted

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.

quoted

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