Re: [PATCH] seccomp: passthrough uretprobe systemcall without filtering

[Kees Cook <kees@kernel.org>]

On January 18, 2025 12:45:47 PM PST, Eyal Birger <eyal.birger@gmail.com> wrote:
>I think the difference is that this syscall is not part of the process's
>code - it is inserted there by another process tracing it.

Well that's nothing like syscall_restart, and now I'm convinced seccomp must never ignore uretprobe -- a process might want to block uretprobe!

So, no, sorry, this needs to be handled by the seccomp policy that is applied to the process.

>So this is different than desiring to deploy a new version of a binary
>that uses a new libc or a new syscall.

Uh, no, the case I used as an example was no changes to anything except the kernel. Libc noticed the available syscall, uses it, and is instantly killed by the Docker seccomp policy which didn't know about that syscall.

> Here the case is that there are
>three players - the tracer running out of docker, the tracee running in docker,
>and docker itself. All three were running fine in a specific kernel version,
>but upgrading the kernel now crashes the traced process.

If uretprobe used to work without a syscall, then that seems to be the problem. But I think easiest is just fixing the Docker policy. (Which is a text file configuration change; no new binaries, no rebuilds!).

>I think this syscall is different in that respect for the reasons described.

I don't agree, sorry. Seccomp has a really singular and specific purpose, which is explicitly *externalizing* policy. I do not want to have policy within seccomp itself.

>I don't know if seccomp is behaving correctly when it blocks a kernel
>implementation detail that isn't user created.

But it is user created? Something added a uretprobe to a process who's seccomp policy is not expecting it. This seems precisely by design.

-Kees

-- 
Kees Cook