From: Steve Dower <steve.dower@python.org>
To: "Mickaël Salaün" <mic@digikod.net>, "Jeff Xu" <jeffxu@google.com>
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: Wed, 10 Jul 2024 17:32:36 +0100 [thread overview]
Message-ID: <296b11b2-5ff2-488b-ac4c-7945aabd7b3c@python.org> (raw)
In-Reply-To: <20240710.eiKohpa4Phai@digikod.net>
On 10/07/2024 10:58, Mickaël Salaün wrote:
> On Tue, Jul 09, 2024 at 02:57:43PM -0700, Jeff Xu wrote:
>>> Hmm, I'm not sure this "CHECK=0, RESTRICT=1" configuration would make
>>> sense for a dynamic linker except maybe if we want to only allow static
>>> binaries?
>>>
>>> The CHECK and RESTRICT securebits are designed to make it possible a
>>> "permissive mode" and an enforcement mode with the related locked
>>> securebits. This is why this "CHECK=0, RESTRICT=1" combination looks a
>>> bit weird. We can replace these securebits with others but I didn't
>>> find a better (and simple) option. I don't think this is an issue
>>> because with any security policy we can create unusable combinations.
>>> The three other combinations makes a lot of sense though.
>>>
>> If we need only handle 3 combinations, I would think something like
>> below is easier to understand, and don't have wield state like
>> CHECK=0, RESTRICT=1
>
> The "CHECK=0, RESTRICT=1" is useful for script interpreter instances
> that should not interpret any command from users e.g., but only execute
> script files.
I see this case as being most relevant to something that doesn't usually
need any custom scripts, but may have it. For example, macros in a
document, or pre/post-install scripts for a package manager.
For something whose sole purpose is to execute scripts, it doesn't make
much sense. But there are other cases that can be reasonably controlled
with this option.
Cheers,
Steve
next prev parent reply other threads:[~2024-07-10 16:36 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
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 [this message]
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=296b11b2-5ff2-488b-ac4c-7945aabd7b3c@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).