On Thu, May 14, 2020 at 08:22:01AM -0400, Stephen Smalley wrote: > On Wed, May 13, 2020 at 11:05 PM Kees Cook <keesc...@chromium.org> wrote: > > > > On Wed, May 13, 2020 at 04:27:39PM -0700, Kees Cook wrote: > > > Like, couldn't just the entire thing just be: > > > > > > diff --git a/fs/namei.c b/fs/namei.c > > > index a320371899cf..0ab18e19f5da 100644 > > > --- a/fs/namei.c > > > +++ b/fs/namei.c > > > @@ -2849,6 +2849,13 @@ static int may_open(const struct path *path, int > > > acc_mode, int flag) > > > break; > > > } > > > > > > + if (unlikely(mask & MAY_OPENEXEC)) { > > > + if (sysctl_omayexec_enforce & OMAYEXEC_ENFORCE_MOUNT && > > > + path_noexec(path)) > > > + return -EACCES; > > > + if (sysctl_omayexec_enforce & OMAYEXEC_ENFORCE_FILE) > > > + acc_mode |= MAY_EXEC; > > > + } > > > error = inode_permission(inode, MAY_OPEN | acc_mode); > > > if (error) > > > return error; > > > > > > > FYI, I've confirmed this now. Effectively with patch 2 dropped, patch 3 > > reduced to this plus the Kconfig and sysctl changes, the self tests > > pass. > > > > I think this makes things much cleaner and correct. > > I think that covers inode-based security modules but not path-based > ones (they don't implement the inode_permission hook). For those, I > would tentatively guess that we need to make sure FMODE_EXEC is set on > the open file and then they need to check for that in their file_open > hooks.
Does there need to be an FMODE_OPENEXEC, or is the presence of FMODE_OPEN with FMODE_EXEC sufficient? -- Kees Cook