On Sat, Jan 18, 2025 at 12:21:51PM -0800, Kees Cook wrote:

On Thu, Jan 16, 2025 at 04:55:39PM -0800, Eyal Birger wrote:

quoted

Since uretprobe is a "kernel implementation detail" system call which is
not used by userspace application code directly, it is impractical and
there's very little point in forcing all userspace applications to
explicitly allow it in order to avoid crashing tracked processes.

How is this any different from sigreturn, rt_sigreturn, or
restart_syscall? These are all handled explicitly by userspace filters
already, and I don't see why uretprobe should be any different. Docker
has had plenty of experience with fixing their seccomp filters for new
syscalls. For example, many times already a given libc will suddenly
start using a new syscall when it sees its available, etc.

Basically, this is a Docker issue, not a kernel issue. Seccomp is
behaving correctly. I don't want to start making syscalls invisible
without an extremely good reason. If _anything_ should be invisible, it
is restart_syscall (which actually IS invisible under certain
architectures).

I was wondering that too -- if ______'s security policy is to disallow
by default, then fix the security policy.  Don't blow a hole in seccomp
for all users.  Maybe someone *wants* to block uretprobe.  Maybe doing
so will be needed some day as a crude mitigation for a zeroday.

--D

-Kees

-- 
Kees Cook