Re: [PATCH v3 6/7] seccomp: allow nested listeners

[Aleksa Sarai]

On 2026-01-20, Andrei Vagin <avagin@xxxxxxxxx> wrote:
> On Thu, Dec 11, 2025 at 4:46 AM Alexander Mikhalitsyn
> <aleksandr.mikhalitsyn@xxxxxxxxxxxxx> wrote:
> >
> > Now everything is ready to get rid of "only one listener per tree"
> > limitation.
> >
> > Let's introduce a new uAPI flag
> > SECCOMP_FILTER_FLAG_ALLOW_NESTED_LISTENERS, so userspace may explicitly
> > allow nested listeners when installing a listener.
> 
> I am not sure we really need SECCOMP_FILTER_FLAG_ALLOW_NESTED_LISTENERS.
> If nested listeners are completely functional, why would we want to
> implicitly allow or disallow someone from using them?

It can be quite easy to deadlock a process using seccomp-notify (even
in the single-notifier case) so especially in the case of container
managers I can see the argument for wanting this to be an opt-in thing
once container runtimes have verified their notifier won't break
nesting.

Then again, you can also use seccomp to block
SECCOMP_FILTER_FLAG_NEW_LISTENER directly, so you don't really need a
separate flag to allow nested listeners (unless I'm missing something)?
That would make it opt-out but presumably filters that allow seccomp
already use an allow-list for flags.

> Actually, even the current behavior of SECCOMP_RET_USER_NOTIF looks a
> bit illogical. I think the following behavior would be more expected:
> instead of running all filters and picking the most restrictive result,
> the kernel should execute them one by one (most recent fist). If a filter
> returns USER_NOTIF, the kernel pauses immediately to let the listener
> handle the call. If that listener then issues "CONTINUE", the kernel
> resumes by running the remaining older filters in the chain.

I guess there is a philosophical argument that earlier filters are "more
trusted" but the seccomp security model has always been that the
strictest filter return wins and I don't really see a strong argument
for deviating from that for USER_NOTIF.

-- 
Aleksa Sarai
https://www.cyphar.com/

Attachment: signature.asc
Description: PGP signature