From: Kees Cook <keescook@chromium.org>
To: "Mickaël Salaün" <mic@digikod.net>
Cc: concord@gentoo.org, linux-hardening@vger.kernel.org,
"Linus Torvalds" <torvalds@linux-foundation.org>,
"Al Viro" <viro@zeniv.linux.org.uk>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Christian Heimes" <christian@python.org>,
"Geert Uytterhoeven" <geert@linux-m68k.org>,
"James Morris" <jmorris@namei.org>,
"Luis Chamberlain" <mcgrof@kernel.org>,
"Mimi Zohar" <zohar@linux.ibm.com>,
"Muhammad Usama Anjum" <usama.anjum@collabora.com>,
"Paul Moore" <paul@paul-moore.com>,
"Philippe Trébuchet" <philippe.trebuchet@ssi.gouv.fr>,
"Shuah Khan" <skhan@linuxfoundation.org>,
"Steve Dower" <steve.dower@python.org>,
"Thibaut Sautereau" <thibaut.sautereau@ssi.gouv.fr>,
"Vincent Strubel" <vincent.strubel@ssi.gouv.fr>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-integrity <linux-integrity@vger.kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"LSM List" <linux-security-module@vger.kernel.org>,
"Christian Brauner" <brauner@kernel.org>,
"Theodore Ts'o" <tytso@mit.edu>
Subject: Re: [GIT PULL] Add trusted_for(2) (was O_MAYEXEC)
Date: Wed, 8 Feb 2023 11:32:23 -0800 [thread overview]
Message-ID: <63e3f8c8.050a0220.c0b3f.434b@mx.google.com> (raw)
In-Reply-To: <7e8d9f8a-f119-6d1a-7861-0493dc513aa7@digikod.net>
*thread necromancy*
On Tue, Apr 05, 2022 at 06:09:03PM +0200, Mickaël Salaün wrote:
>
> On 05/04/2022 01:26, Linus Torvalds wrote:
> > On Mon, Apr 4, 2022 at 3:25 PM Kees Cook <keescook@chromium.org> wrote:
>
> [...]
>
> >
> > > I think this already exists as AT_EACCESS? It was added with
> > > faccessat2() itself, if I'm reading the history correctly.
> >
> > Yeah, I noticed myself, I just hadn't looked (and I don't do enough
> > user-space programming to be aware of if that way).
>
> I think AT_EACCESS should be usable with the new EXECVE_OK too.
>
>
> >
> > > > (a) "what about suid bits that user space cannot react to"
> > >
> > > What do you mean here? Do you mean setid bits on the file itself?
> >
> > Right.
> >
> > Maybe we don't care.
>
> I think we don't. I think the only corner case that could be different is
> for files that are executable, SUID and non-readable. In this case it
> wouldn't matter because userspace could not read the file, which is required
> for interpretation/execution. Anyway, S[GU]ID bits in scripts are just
> ignored by execve and we want to follow the same semantic.
Hi Mickaël,
Is there a new version of this being worked on? It would be really nice
to have the O_MAYEXEC/faccessat2() visibility for script execution control
in userspace. It seems like it would be mainly a respin of an earlier
version of this series before trusted_for() was proposed.
-Kees
--
Kees Cook
next prev parent reply other threads:[~2023-02-08 19:32 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-21 16:15 [GIT PULL] Add trusted_for(2) (was O_MAYEXEC) Mickaël Salaün
2022-03-21 17:38 ` Luis Chamberlain
2022-03-21 18:05 ` Mickaël Salaün
2022-03-21 23:32 ` Luis Chamberlain
2022-03-30 16:06 ` Mickaël Salaün
2022-04-04 18:40 ` Kees Cook
2022-04-04 18:47 ` Linus Torvalds
2022-04-04 20:30 ` Mickaël Salaün
2022-04-04 21:28 ` Linus Torvalds
2022-04-04 21:40 ` Linus Torvalds
2022-04-04 22:25 ` Kees Cook
2022-04-04 23:26 ` Linus Torvalds
2022-04-05 16:09 ` Mickaël Salaün
2022-04-05 16:17 ` Linus Torvalds
2023-02-08 19:32 ` Kees Cook [this message]
2023-02-09 15:43 ` Mickaël Salaün
2022-04-05 22:21 ` Theodore Ts'o
2022-04-05 15:55 ` Mickaël Salaün
2022-04-05 15:38 ` Mickaël Salaün
2022-04-05 14:54 ` Theodore Ts'o
2022-04-05 16:14 ` 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=63e3f8c8.050a0220.c0b3f.434b@mx.google.com \
--to=keescook@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=christian@python.org \
--cc=concord@gentoo.org \
--cc=geert@linux-m68k.org \
--cc=jmorris@namei.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=mic@digikod.net \
--cc=paul@paul-moore.com \
--cc=philippe.trebuchet@ssi.gouv.fr \
--cc=skhan@linuxfoundation.org \
--cc=steve.dower@python.org \
--cc=thibaut.sautereau@ssi.gouv.fr \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--cc=usama.anjum@collabora.com \
--cc=vincent.strubel@ssi.gouv.fr \
--cc=viro@zeniv.linux.org.uk \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.