linux-kernel - 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-next>] [day] [month] [year] [list]

Date:   Tue, 29 Jun 2021 17:54:24 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     <linux-api@...r.kernel.org>
Cc:     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: Semantics of SECCOMP_MODE_STRICT?

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?

Thank you,
Eric