[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 14 May 2020 11:52:07 -0400
From: Stephen Smalley <stephen.smalley.work@...il.com>
To: Kees Cook <keescook@...omium.org>
Cc: Mickaël Salaün <mic@...ikod.net>,
linux-kernel <linux-kernel@...r.kernel.org>, Aleksa Sarai <cyphar@...har.com>,
Alexei Starovoitov <ast@...nel.org>, Al Viro <viro@...iv.linux.org.uk>,
Andy Lutomirski <luto@...nel.org>, Christian Heimes <christian@...hon.org>,
Daniel Borkmann <daniel@...earbox.net>, Deven Bowers <deven.desai@...ux.microsoft.com>,
Eric Chiang <ericchiang@...gle.com>, Florian Weimer <fweimer@...hat.com>,
James Morris <jmorris@...ei.org>, Jan Kara <jack@...e.cz>, Jann Horn <jannh@...gle.com>,
Jonathan Corbet <corbet@....net>, Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>,
Matthew Garrett <mjg59@...gle.com>, Matthew Wilcox <willy@...radead.org>,
Michael Kerrisk <mtk.manpages@...il.com>, Mickaël Salaün <mickael.salaun@....gouv.fr>,
Mimi Zohar <zohar@...ux.ibm.com>,
Philippe Trébuchet <philippe.trebuchet@....gouv.fr>,
Scott Shell <scottsh@...rosoft.com>,
Sean Christopherson <sean.j.christopherson@...el.com>, Shuah Khan <shuah@...nel.org>,
Steve Dower <steve.dower@...hon.org>, Steve Grubb <sgrubb@...hat.com>,
Thibaut Sautereau <thibaut.sautereau@....gouv.fr>,
Vincent Strubel <vincent.strubel@....gouv.fr>, kernel-hardening@...ts.openwall.com,
linux-api@...r.kernel.org, linux-integrity@...r.kernel.org,
LSM List <linux-security-module@...r.kernel.org>,
Linux FS Devel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH v5 3/6] fs: Enable to enforce noexec mounts or file exec
through O_MAYEXEC
On Thu, May 14, 2020 at 10:41 AM Kees Cook <keescook@...omium.org> wrote:
>
> On Thu, May 14, 2020 at 08:22:01AM -0400, Stephen Smalley wrote:
> > On Wed, May 13, 2020 at 11:05 PM Kees Cook <keescook@...omium.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?
I don't think we need an extra flag/mode bit. But note that 1)
FMODE_OPENED isn't set until after security_file_open() is called so
we can't rely on it there, 2) __FMODE_EXEC aka FMODE_EXEC is set in
f_flags not f_mode, 3) FMODE_EXEC was originally introduced for
distributed filesystems so that they could return ETXTBUSY if the file
was opened for write and execute on different nodes, 4) AppArmor and
TOMOYO have special handling of execve based on current->in_execve so
I guess the only overlap would be for uselib(2).
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
