Re: [PATCH 2/4] seccomp, bpf: Introduce SECCOMP_LOAD_FILTER operation

[Hengqi Chen]

On Wed, Oct 11, 2023 at 8:24 AM Kees Cook <keescook@xxxxxxxxxxxx> wrote:
>
> On Mon, Oct 09, 2023 at 12:40:44PM +0000, Hengqi Chen wrote:
> > This patch adds a new operation named SECCOMP_LOAD_FILTER.
> > It accepts the same arguments as SECCOMP_SET_MODE_FILTER
> > but only performs the loading process. If succeed, return a
> > new fd associated with the JITed BPF program (the filter).
> > The filter can then be pinned to bpffs using the returned
> > fd and reused for different processes. To distinguish the
> > filter from other BPF progs, BPF_PROG_TYPE_SECCOMP is added.
> >
> > Signed-off-by: Hengqi Chen <hengqi.chen@xxxxxxxxx>
>
> This part looks okay, I think. I need to spend some more time looking at
> the BPF side. I want to make sure it is only possible to build a
> BPF_PROG_TYPE_SECCOMP prog by going through seccomp. I want to make sure
> we can never side-load some kind of unexpected program into seccomp,
> etc. Since BPF_PROG_TYPE_SECCOMP is part of UAPI, is this controllable
> through the bpf() syscall?
>

Currently, it failed at find_prog_type() since we don't register the
prog type to BPF.

> One thought I had, though, is I wonder if flags are needed to be
> included with the fd? I'll ponder this a bit more...
>

bpf_prog_new_fd() already set O_RDWR and O_CLOEXEC.

> --
> Kees Cook