Messages in this thread | | | From | Hengqi Chen <> | Date | Thu, 12 Oct 2023 09:48:22 +0800 | Subject | Re: [PATCH 2/4] seccomp, bpf: Introduce SECCOMP_LOAD_FILTER operation |
| |
On Wed, Oct 11, 2023 at 8:24 AM Kees Cook <keescook@chromium.org> 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@gmail.com> > > 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
| |