Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <ef9b8445-b02b-3f6a-a566-587695f322b7@iogearbox.net> <20230118111854.744810-1-clangllvm@126.com>
In-Reply-To: <20230118111854.744810-1-clangllvm@126.com>
From:   Djalal Harouni <tixxdz@gmail.com>
Date:   Wed, 18 Jan 2023 16:36:06 +0100
Message-ID: <CAEiveUd_N8qHy54AS0q90FuUSQ=7mePm8FL88Aw-sY7fT7NqFQ@mail.gmail.com>
Subject: Re: [PATCH V2] bpf: security enhancement by limiting the offensive
 eBPF helpers
To:     Yi He <clangllvm@126.com>
Cc:     daniel@iogearbox.net, andrii@kernel.org, ast@kernel.org,
        bpf@vger.kernel.org, haoluo@google.com, john.fastabend@gmail.com,
        jolsa@kernel.org, kpsingh@kernel.org, linux-kernel@vger.kernel.org,
        linux-trace-kernel@vger.kernel.org, martin.lau@linux.dev,
        mhiramat@kernel.org, rostedt@goodmis.org, sdf@google.com,
        song@kernel.org, yhs@fb.com, yhs@meta.com,
        linux-security-module@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Jan 18, 2023 at 1:38 PM Yi He <clangllvm@126.com> wrote:
[...]
> Thanks for your feedback.
>
> This patch aims to mitigate the offensive eBPF problem which has been dic=
ussed since 2019 [1]. Recently, we find that enable eBPF in container envir=
onemnt can lead to container escape or cross-nodes attacks (which may compr=
omise mutiple VMs) in the Kubernetes [2]. Since lots of eBPF based tools ar=
e used in containers, mutiple containers have the CAP_SYS_ADMIN needed by e=
BPF which may be abused by untrusted eBPF code.

Then solution should be toward restricting eBPF in container, there is alre=
ady
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 fo=
r 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 proce=
ss. 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 lockdow=
n.

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!