From: ebiederm@xmission.com (Eric W. Biederman)
To: Kees Cook <keescook@chromium.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
Eric Biggers <ebiggers3@gmail.com>,
Dmitry Vyukov <dvyukov@google.com>,
linux-fsdevel@vger.kernel.org,
linux-security-module@vger.kernel.org, linux-api@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] Relocate execve() sanity checks
Date: Tue, 19 May 2020 10:06:32 -0500 [thread overview]
Message-ID: <87a724t153.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20200518055457.12302-1-keescook@chromium.org> (Kees Cook's message of "Sun, 17 May 2020 22:54:53 -0700")
Kees Cook <keescook@chromium.org> writes:
> Hi,
>
> While looking at the code paths for the proposed O_MAYEXEC flag, I saw
> some things that looked like they should be fixed up.
>
> exec: Change uselib(2) IS_SREG() failure to EACCES
> This just regularizes the return code on uselib(2).
>
> exec: Relocate S_ISREG() check
> This moves the S_ISREG() check even earlier than it was already.
>
> exec: Relocate path_noexec() check
> This adds the path_noexec() check to the same place as the
> S_ISREG() check.
>
> fs: Include FMODE_EXEC when converting flags to f_mode
> This seemed like an oversight, but I suspect there is some
> reason I couldn't find for why FMODE_EXEC doesn't get set in
> f_mode and just stays in f_flags.
So I took a look at this series.
I think the belt and suspenders approach of adding code in open and then
keeping it in exec and uselib is probably wrong. My sense of the
situation is a belt and suspenders approach is more likely to be
confusing and result in people making mistakes when maintaining the code
than to actually be helpful.
Eric
next prev parent reply other threads:[~2020-05-19 15:10 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-18 5:54 [PATCH 0/4] Relocate execve() sanity checks Kees Cook
2020-05-18 5:54 ` [PATCH 1/4] exec: Change uselib(2) IS_SREG() failure to EACCES Kees Cook
2020-05-18 13:02 ` Christian Brauner
2020-05-18 14:43 ` Jann Horn
2020-05-18 14:46 ` Christian Brauner
2020-05-18 23:57 ` Eric W. Biederman
2020-05-19 8:11 ` Christian Brauner
2020-05-19 8:37 ` Andreas Schwab
2020-05-19 11:56 ` Eric W. Biederman
2020-05-19 12:12 ` Andreas Schwab
2020-05-19 12:28 ` Eric W. Biederman
2020-05-19 13:29 ` Christian Brauner
2020-05-19 14:49 ` Eric W. Biederman
2020-05-19 13:13 ` Christian Brauner
2020-05-19 14:32 ` Geert Uytterhoeven
2020-05-19 14:47 ` Christian Brauner
2020-05-18 5:54 ` [PATCH 2/4] exec: Relocate S_ISREG() check Kees Cook
[not found] ` <20200525091420.GI12456@shao2-debian>
2020-06-04 22:45 ` [exec] 166d03c9ec: ltp.execveat02.fail Kees Cook
2020-06-05 2:57 ` Kees Cook
2020-05-18 5:54 ` [PATCH 3/4] exec: Relocate path_noexec() check Kees Cook
2020-05-18 5:54 ` [PATCH 4/4] fs: Include FMODE_EXEC when converting flags to f_mode Kees Cook
2020-05-19 15:06 ` Eric W. Biederman [this message]
2020-05-19 16:26 ` [PATCH 0/4] Relocate execve() sanity checks Kees Cook
2020-05-19 17:41 ` Eric W. Biederman
2020-05-19 17:56 ` Kees Cook
2020-05-19 18:42 ` Eric W. Biederman
2020-05-19 21:17 ` Kees Cook
2020-05-19 22:58 ` John Johansen
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=87a724t153.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=dvyukov@google.com \
--cc=ebiggers3@gmail.com \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=viro@zeniv.linux.org.uk \
/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).