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:
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