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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2026-01-21-tame-yapping-name-paste-hnBZQp@cyphar.com>
Date: Wed, 21 Jan 2026 16:43:29 +0100
From: Aleksa Sarai <cyphar@...har.com>
To: Andrei Vagin <avagin@...il.com>
Cc: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@...onical.com>, 
	kees@...nel.org, linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, 
	bpf@...r.kernel.org, Andy Lutomirski <luto@...capital.net>, 
	Will Drewry <wad@...omium.org>, Jonathan Corbet <corbet@....net>, Shuah Khan <shuah@...nel.org>, 
	Tycho Andersen <tycho@...ho.pizza>, Christian Brauner <brauner@...nel.org>, 
	Stéphane Graber <stgraber@...raber.org>, Alexander Mikhalitsyn <alexander@...alicyn.com>
Subject: Re: [PATCH v3 6/7] seccomp: allow nested listeners

On 2026-01-20, Andrei Vagin <avagin@...il.com> wrote:
> On Thu, Dec 11, 2025 at 4:46 AM Alexander Mikhalitsyn
> <aleksandr.mikhalitsyn@...onical.com> 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/

Download attachment "signature.asc" of type "application/pgp-signature" (266 bytes)