Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 29 Jun 2021 22:23:06 -0700
From:   Kees Cook <keescook@chromium.org>
To:     "Eric W. Biederman" <ebiederm@xmission.com>
Cc:     linux-api@vger.kernel.org, Andy Lutomirski <luto@amacapital.net>,
        Will Drewry <wad@chromium.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Al Viro <viro@zeniv.linux.org.uk>,
        Michael Kerrisk <mtk.manpages@gmail.com>,
        linux-man@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Semantics of SECCOMP_MODE_STRICT?
Message-ID: <202106292156.9458CF22@keescook>
References: <87r1gkp9i7.fsf@disp2133>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87r1gkp9i7.fsf@disp2133>
Precedence: bulk

On Tue, Jun 29, 2021 at 05:54:24PM -0500, Eric W. Biederman wrote:
> 
> I am the process of cleaning up the process exit path in the kernel, and
> as part of that I am looking at the callers of do_exit.  A very
> interesting one is __seccure_computing_strict.
> 
> Looking at the code is very clear that if a system call is attempted
> that is not in the table the thread attempting to execute that system
> call is terminated.
> 
> Reading the man page for seccomp it says that the process is delivered
> SIGKILL.
> 
> The practical difference is what happens for multi-threaded
> applications.
> 
> What are the desired semantics for a multi-threaded application if one
> thread attempts to use a unsupported system call?  Should the thread be
> terminated or the entire application?
> 
> Do we need to fix the kernel, or do we need to fix the manpages?

I don't know of anyone actually using SECCOMP_MODE_STRICT, but the
original implementation was (perhaps accidentally) thread-killing. It
turns out this is not a particularly desirable situation, and when
SECCOMP_MODE_FILTER was created, it continued with that semantic,
but later grew a process-killing flags, as that's what most programs
actually wanted.

It's likely the manpage needs fixing (we had to make similar updates
for SECCOMP_MODE_FILTER), since some of the early examples of using
SECCOMP_MODE_STRICT were basically "fork, calculate, write result to
fd, exit".

FWIW the seccomp selftests don't even check for the thread-vs-process
SIGKILL of SECCOMP_MODE_STRICT. :)

-- 
Kees Cook