Re: [RFC] Proposal: Static SECCOMP Policies

[Kees Cook <kees@kernel.org>]

On Thu, Sep 12, 2024 at 04:02:53PM +0000, Maxwell Bland wrote:
> operated on around 0.1188 MB). But most importantly, third, without some degree
> of provenance, I have no way of telling if someone has injected malicious code
> into the kernel, and unfortunately even knowing the correct bytes is still
> "iffy", as in order to prevent JIT spray attacks, each of these filters is
> offset by some random number of uint32_t's, making every 4-byte shift of the
> filter a "valid" codepage to be loaded at runtime.

I wanted to focus this thread on the problem, rather than potential
solutions. I think we risk losing sight of getting a complete description
of what is needed if we dive into solutions too quickly.

So, let's start here. What I've seen from the thread is that there isn't
a way to verify that a given JIT matches the cBPF. Is validating the
cBPF itself also needed?

This reminds me of two related topics, which might help either better
define the problem or help find some other folks with similar needs.

- The IMA subsystem has wanted a way to measure (and validate) seccomp
  filters. We could get more details from them for defining this need
  more clearly.

- The JIT needs to be verified against the cBPF that it was generated
  from. We currently do only a single pass and don't validate it once
  the region has been set read-only. We have a standing feature request
  for improving this: https://github.com/KSPP/linux/issues/154

For solutions, I didn't see much discussion around the "orig_prog"
copy of the cBPF. Under CHECKPOINT_RESTORE, the original cBPF remains
associated with the JIT. struct seccomp_filter's struct bpf_prog prog's
orig_prog member. If it has value outside of CHECKPOINT_RESTORE, then
we could do it for those conditions too.

-Kees

-- 
Kees Cook