linux-kernel - Re: Semantics of SECCOMP_MODE

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: <20210630050219.nwixaloqs5oq5juy@senku>
Date:   Wed, 30 Jun 2021 15:02:19 +1000
From:   Aleksa Sarai <cyphar@...har.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     linux-api@...r.kernel.org, Kees Cook <keescook@...omium.org>,
        Andy Lutomirski <luto@...capital.net>,
        Will Drewry <wad@...omium.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Al Viro <viro@...IV.linux.org.uk>,
        Michael Kerrisk <mtk.manpages@...il.com>,
        linux-man@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Semantics of SECCOMP_MODE_STRICT?

On 2021-06-29, Eric W. Biederman <ebiederm@...ssion.com> 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?

My expectation is that the correct action should be the equivalent of
SECCOMP_RET_KILL(_THREAD) which kills the thread and is the current
behaviour (SECCOMP_RET_KILL_PROCESS is relatively speaking quite new).

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

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