Kees Cook <keescook@xxxxxxxxxxxx> [Tue, 2019-04-09 09:51 -0700]: > 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: > > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__facebookmicrosites.github.io_bpf_blog_2018_08_31_object-2Dlifetime.html&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=3jAokpHyGuCuJ834j-tttQ&m=ZJJ4QMXnksL1b4VPoBM0NJ0i6OWysGc2Om26pcoJpxA&s=6dIZ788hOzoDWVif5XQ-9Mqf9ijko9O7TOWArLzblxU&e= > > 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...) Since I answered similar question from Jann below, I'll answer it here as well (even though it was addressed to Alexei). Stacking can be controlled by attach flags (NONE, BPF_F_ALLOW_OVERRIDE, BPF_F_ALLOW_MULTI) described in include/uapi/linux/bpf.h. Basically if one attaches a program to a cgroup with `bpf_attr.attach_flags = 0` (0 is "NONE"), then nobody can override it by their own programs of same type in any sub-cgroup. It can be hardened further by cgroup namespace so that in-container root doesn't even see part of cgroup hierarchy where cgroup-bpf program is attached to with attach flags NONE. -- Andrey Ignatov
