Kees Cook [off-list ref] 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
On Tue, May 19, 2020 at 10:06:32AM -0500, Eric W. Biederman wrote:
Kees Cook [off-list ref] writes:
quoted
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.
This is why I added the comments in fs/exec.c's redundant checks. When I
was originally testing this series, I had entirely removed the checks in
fs/exec.c, but then had nightmares about some kind of future VFS paths
that would somehow bypass do_open() and result in execve() working on
noexec mounts, there by allowing for the introduction of a really nasty
security bug.
The S_ISREG test is demonstrably too late (as referenced in the series),
and given the LSM hooks, I think the noexec check is too late as well.
(This is especially true for the coming O_MAYEXEC series, which will
absolutely need those tests earlier as well[1] -- the permission checking
is then in the correct place: during open, not exec.) I think the only
question is about leaving the redundant checks in fs/exec.c, which I
think are a cheap way to retain a sense of robustness.
-Kees
[1] https://lore.kernel.org/lkml/202005142343.D580850@keescook/
--
Kees Cook