On Wed, Jan 18, 2023 at 1:38 PM Yi He <clangllvm@xxxxxxx> wrote: [...] > Thanks for your feedback. > > This patch aims to mitigate the offensive eBPF problem which has been dicussed since 2019 [1]. Recently, we find that enable eBPF in container environemnt can lead to container escape or cross-nodes attacks (which may compromise mutiple VMs) in the Kubernetes [2]. Since lots of eBPF based tools are used in containers, mutiple containers have the CAP_SYS_ADMIN needed by eBPF which may be abused by untrusted eBPF code. Then solution should be toward restricting eBPF in container, there is already sysctl, per process seccomp, LSM + bpf LSM for that. ... > > I'm not applying this.. i) this means by default you effectively remove these > > helpers from existing users in the wild given integrity mode is default for > > secure boot, but also ii) should we lock-down and remove the ability for other > > privileged entities like processes to send signals, seccomp to ret_kill, ptrace, > > etc given they all "can affect userspace processes" > > It does not affect other privielge processes (e.g., ptrace) to kill process. Seccomp is classic bpf does not use this eBPF helper [4]. Those are more or less same as bpf sending signal. Supervisors are using seccomp to ret kill process and/or sending signals. Where will you draw the line? should we go restrict those too? IMHO this does not relate to lockdown. This reasoning will kill any effort to improve sandbox mechanisms that are moving some functionality from seccomp ret kill to a more flexible and transparent bpf-LSM model where privileged installs the sandbox. Actually, we are already doing this and beside eBPF flexibility and transparency (change policy at runtime without restart) from a _user perspective_ I don't see that much difference between a seccomp kill and ebpf signal. Thanks!
