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 >
