On Mon, Jan 27, 2025 at 11:39:44AM -0800, Eyal Birger wrote:

On Mon, Jan 27, 2025 at 11:33 AM Kees Cook [off-list ref] wrote:

quoted

On Mon, Jan 27, 2025 at 11:24:02AM -0800, Eyal Birger wrote:

quoted

Hi Kees,

On Mon, Jan 20, 2025 at 1:34 PM Kees Cook [off-list ref] wrote:

quoted

On Sat, Jan 18, 2025 at 07:39:25PM -0800, Eyal Birger wrote:

quoted

Alternatively, maybe this syscall implementation should be reverted?

Honestly, that seems the best choice. I don't think any thought was
given to how it would interact with syscall interposers (including
ptrace, strict mode seccomp, etc).

I don't know if you noticed Andrii's and others' comments on this [1].

Given that:
- this issue requires immediate remediation
- there seems to be pushback for reverting the syscall implementation
- filtering uretprobe is not within the capabilities of seccomp without this
  syscall (so reverting the syscall is equivalent to just passing it through
  seccomp)

is it possible to consider applying this current fix, with the possibility of
extending seccomp in the future to support filtering uretprobe if deemed
necessary (for example by allowing userspace to define a stricter policy)?

I still think this is a Docker problem, but I agree that uretprobe
without syscall is just as unfilterable as seccomp ignoring the syscall.

Can you please update the patch to use the existing action_cache bitmaps
instead of adding an open-coded check? We can consider adding
syscall_restart to this as well in the future...

I can. The main difference as far as I can tell is that it would not
apply to strict mode. Is that OK? it means that existing binaries using
strict mode would still crash if uretprobe is attached to them.

Ah, good point. Please also add it to mode1_syscalls for strict. :)

-- 
Kees Cook