From: Steve Dower <steve.dower@python.org>
To: "Jeff Xu" <jeffxu@google.com>, "Mickaël Salaün" <mic@digikod.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>,
Kees Cook <keescook@chromium.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Paul Moore <paul@paul-moore.com>, Theodore Ts'o <tytso@mit.edu>,
Alejandro Colomar <alx@kernel.org>,
Aleksa Sarai <cyphar@cyphar.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Casey Schaufler <casey@schaufler-ca.com>,
Christian Heimes <christian@python.org>,
Dmitry Vyukov <dvyukov@google.com>,
Eric Biggers <ebiggers@kernel.org>,
Eric Chiang <ericchiang@google.com>,
Fan Wu <wufan@linux.microsoft.com>,
Florian Weimer <fweimer@redhat.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
James Morris <jamorris@linux.microsoft.com>,
Jan Kara <jack@suse.cz>, Jann Horn <jannh@google.com>,
Jonathan Corbet <corbet@lwn.net>,
Jordan R Abrahams <ajordanr@google.com>,
Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
Luca Boccassi <bluca@debian.org>,
Luis Chamberlain <mcgrof@kernel.org>,
"Madhavan T . Venkataraman" <madvenka@linux.microsoft.com>,
Matt Bobrowski <mattbobrowski@google.com>,
Matthew Garrett <mjg59@srcf.ucam.org>,
Matthew Wilcox <willy@infradead.org>,
Miklos Szeredi <mszeredi@redhat.com>,
Mimi Zohar <zohar@linux.ibm.com>,
Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>,
Scott Shell <scottsh@microsoft.com>,
Shuah Khan <shuah@kernel.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Steve Grubb <sgrubb@redhat.com>,
Thibaut Sautereau <thibaut.sautereau@ssi.gouv.fr>,
Vincent Strubel <vincent.strubel@ssi.gouv.fr>,
Xiaoming Ni <nixiaoming@huawei.com>,
Yin Fengwei <fengwei.yin@intel.com>,
kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-integrity@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org
Subject: Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
Date: Mon, 8 Jul 2024 22:25:41 +0100 [thread overview]
Message-ID: <ef3281ad-48a5-4316-b433-af285806540d@python.org> (raw)
In-Reply-To: <CALmYWFuVJiRZgB0ye9eR95dvBOigoOVShgS9i_ESjEre-H5pLA@mail.gmail.com>
On 08/07/2024 22:15, Jeff Xu wrote:
> IIUC:
> CHECK=0, RESTRICT=0: do nothing, current behavior
> CHECK=1, RESTRICT=0: permissive mode - ignore AT_CHECK results.
> CHECK=0, RESTRICT=1: call AT_CHECK, deny if AT_CHECK failed, no exception.
> CHECK=1, RESTRICT=1: call AT_CHECK, deny if AT_CHECK failed, except
> those in the "checked-and-allowed" list.
I had much the same question for Mickaël while working on this.
Essentially, "CHECK=0, RESTRICT=1" means to restrict without checking.
In the context of a script or macro interpreter, this just means it will
never interpret any scripts. Non-binary code execution is fully disabled
in any part of the process that respects these bits.
"CHECK=1, RESTRICT=1" means to restrict unless AT_CHECK passes. This
case is the allow list (or whatever mechanism is being used to determine
the result of an AT_CHECK check). The actual mechanism isn't the
business of the script interpreter at all, it just has to refuse to
execute anything that doesn't pass the check. So a generic interpreter
can implement a generic mechanism and leave the specifics to whoever
configures the machine.
The other two case are more obvious. "CHECK=0, RESTRICT=0" is the
zero-overhead case, while "CHECK=1, RESTRICT=0" might log, warn, or
otherwise audit the result of the check, but it won't restrict execution.
Cheers,
Steve
next prev parent reply other threads:[~2024-07-08 21:40 UTC|newest]
Thread overview: 103+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-04 19:01 [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC) Mickaël Salaün
2024-07-04 19:01 ` [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2) Mickaël Salaün
2024-07-05 0:04 ` Kees Cook
2024-07-05 17:53 ` Mickaël Salaün
2024-07-08 19:38 ` Kees Cook
2024-07-05 18:03 ` Florian Weimer
2024-07-06 14:55 ` Mickaël Salaün
2024-07-06 15:32 ` Florian Weimer
2024-07-08 8:56 ` Mickaël Salaün
2024-07-08 16:37 ` [PATCH] binfmt_elf: Fail execution of shared objects with ELIBEXEC (was: Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)) Florian Weimer
2024-07-08 17:34 ` [PATCH] binfmt_elf: Fail execution of shared objects with ELIBEXEC Eric W. Biederman
2024-07-08 17:59 ` Florian Weimer
2024-07-10 10:05 ` [PATCH] binfmt_elf: Fail execution of shared objects with ELIBEXEC (was: Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)) Mickaël Salaün
2024-07-08 16:08 ` [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2) Jeff Xu
2024-07-08 16:25 ` Florian Weimer
2024-07-08 16:40 ` Jeff Xu
2024-07-08 17:05 ` Mickaël Salaün
2024-07-08 17:33 ` Florian Weimer
2024-07-08 17:52 ` Jeff Xu
2024-07-09 9:18 ` Mickaël Salaün
2024-07-09 10:05 ` Florian Weimer
2024-07-09 20:42 ` Mickaël Salaün
2024-07-09 18:57 ` Jeff Xu
2024-07-09 20:41 ` Mickaël Salaün
2024-07-06 8:52 ` Andy Lutomirski
2024-07-07 9:01 ` Mickaël Salaün
2024-07-17 6:33 ` Jeff Xu
2024-07-17 8:26 ` Steve Dower
2024-07-17 10:00 ` Mickaël Salaün
2024-07-18 1:02 ` Andy Lutomirski
2024-07-18 12:22 ` Mickaël Salaün
2024-07-20 1:59 ` Andy Lutomirski
2024-07-20 11:43 ` Jarkko Sakkinen
2024-07-23 13:16 ` Mickaël Salaün
2024-07-23 13:16 ` Mickaël Salaün
2024-07-18 1:51 ` Jeff Xu
2024-07-18 12:23 ` Mickaël Salaün
2024-07-18 22:54 ` Jeff Xu
2024-07-17 10:01 ` Mickaël Salaün
2024-07-18 2:08 ` Jeff Xu
2024-07-18 12:24 ` Mickaël Salaün
2024-07-18 13:03 ` James Bottomley
2024-07-18 15:35 ` Mickaël Salaün
2024-07-19 1:29 ` Jeff Xu
2024-07-19 8:44 ` Mickaël Salaün
2024-07-19 14:16 ` Jeff Xu
2024-07-19 15:04 ` Mickaël Salaün
2024-07-19 15:27 ` Jeff Xu
2024-07-23 13:15 ` Mickaël Salaün
2024-08-05 18:35 ` Jeff Xu
2024-08-09 8:45 ` Mickaël Salaün
2024-08-09 16:15 ` Jeff Xu
2024-07-19 15:12 ` Jeff Xu
2024-07-19 15:31 ` Mickaël Salaün
2024-07-19 17:36 ` Jeff Xu
2024-07-23 13:15 ` Mickaël Salaün
2024-07-18 14:46 ` enh
2024-07-18 15:35 ` Mickaël Salaün
2024-07-04 19:01 ` [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits Mickaël Salaün
2024-07-05 0:18 ` Kees Cook
2024-07-05 17:54 ` Mickaël Salaün
2024-07-05 21:44 ` Kees Cook
2024-07-05 22:22 ` Jarkko Sakkinen
2024-07-06 14:56 ` Mickaël Salaün
2024-07-06 17:28 ` Jarkko Sakkinen
2024-07-06 14:56 ` Mickaël Salaün
2024-07-18 14:16 ` Roberto Sassu
2024-07-18 16:20 ` Mickaël Salaün
2024-07-08 16:17 ` Jeff Xu
2024-07-08 17:53 ` Jeff Xu
2024-07-08 18:48 ` Mickaël Salaün
2024-07-08 21:15 ` Jeff Xu
2024-07-08 21:25 ` Steve Dower [this message]
2024-07-08 22:07 ` Jeff Xu
2024-07-09 20:42 ` Mickaël Salaün
2024-07-09 21:57 ` Jeff Xu
2024-07-10 9:58 ` Mickaël Salaün
2024-07-10 16:26 ` Kees Cook
2024-07-11 8:57 ` Mickaël Salaün
2024-07-16 15:02 ` Jeff Xu
2024-07-16 15:10 ` Steve Dower
2024-07-16 15:15 ` Mickaël Salaün
2024-07-16 15:18 ` Jeff Xu
2024-07-10 16:32 ` Steve Dower
2024-07-20 2:06 ` Andy Lutomirski
2024-07-23 13:15 ` Mickaël Salaün
2024-07-04 19:01 ` [RFC PATCH v19 3/5] selftests/exec: Add tests for AT_CHECK and related securebits Mickaël Salaün
2024-07-04 19:01 ` [RFC PATCH v19 4/5] selftests/landlock: Add tests for execveat + AT_CHECK Mickaël Salaün
2024-07-04 19:01 ` [RFC PATCH v19 5/5] samples/should-exec: Add set-should-exec Mickaël Salaün
2024-07-08 19:40 ` Mimi Zohar
2024-07-09 20:42 ` Mickaël Salaün
2024-07-08 20:35 ` [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC) Mimi Zohar
2024-07-09 20:43 ` Mickaël Salaün
2024-07-16 15:57 ` Roberto Sassu
2024-07-16 16:12 ` James Bottomley
2024-07-16 17:29 ` Boris Lukashev
2024-07-16 17:47 ` Mickaël Salaün
2024-07-17 17:59 ` Boris Lukashev
2024-07-18 13:00 ` Mickaël Salaün
2024-07-16 17:31 ` Mickaël Salaün
2024-07-18 16:21 ` Mickaël Salaün
2024-07-15 20:16 ` Jonathan Corbet
2024-07-16 7:13 ` Mickaël Salaün
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ef3281ad-48a5-4316-b433-af285806540d@python.org \
--to=steve.dower@python.org \
--cc=ajordanr@google.com \
--cc=akpm@linux-foundation.org \
--cc=alx@kernel.org \
--cc=arnd@arndb.de \
--cc=bluca@debian.org \
--cc=brauner@kernel.org \
--cc=casey@schaufler-ca.com \
--cc=christian@python.org \
--cc=corbet@lwn.net \
--cc=cyphar@cyphar.com \
--cc=dvyukov@google.com \
--cc=ebiggers@kernel.org \
--cc=ericchiang@google.com \
--cc=fengwei.yin@intel.com \
--cc=fweimer@redhat.com \
--cc=geert@linux-m68k.org \
--cc=jack@suse.cz \
--cc=jamorris@linux.microsoft.com \
--cc=jannh@google.com \
--cc=jeffxu@google.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@kernel.org \
--cc=madvenka@linux.microsoft.com \
--cc=mattbobrowski@google.com \
--cc=mcgrof@kernel.org \
--cc=mic@digikod.net \
--cc=mjg59@srcf.ucam.org \
--cc=mszeredi@redhat.com \
--cc=nicolas.bouchinet@ssi.gouv.fr \
--cc=nixiaoming@huawei.com \
--cc=nramas@linux.microsoft.com \
--cc=paul@paul-moore.com \
--cc=scottsh@microsoft.com \
--cc=sfr@canb.auug.org.au \
--cc=sgrubb@redhat.com \
--cc=shuah@kernel.org \
--cc=thibaut.sautereau@ssi.gouv.fr \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--cc=vincent.strubel@ssi.gouv.fr \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
--cc=wufan@linux.microsoft.com \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).