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
