On January 18, 2025 12:45:47 PM PST, Eyal Birger <eyal.bir...@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
