From: Paul Moore <paul@paul-moore.com>
To: Kees Cook <kees@kernel.org>
Cc: "Christian Göttsche" <cgzones@googlemail.com>,
linux-security-module@vger.kernel.org,
"Eric Biederman" <ebiederm@xmission.com>,
"Kees Cook" <keescook@chromium.org>,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
"Christian Brauner" <brauner@kernel.org>,
"Jan Kara" <jack@suse.cz>, "James Morris" <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
"Khadija Kamran" <kamrankhadijadj@gmail.com>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Casey Schaufler" <casey@schaufler-ca.com>,
"Alexei Starovoitov" <ast@kernel.org>,
"Ondrej Mosnacek" <omosnace@redhat.com>,
"Roberto Sassu" <roberto.sassu@huawei.com>,
"Alfred Piccioni" <alpic@google.com>,
"John Johansen" <john.johansen@canonical.com>,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 1/2] lsm: introduce new hook security_vm_execstack
Date: Tue, 19 Mar 2024 19:10:02 -0400 [thread overview]
Message-ID: <CAHC9VhTpTbVL4=tchR3Bpcfe0Hsijf5XJ6wsEvU7cu8eUy_iDA@mail.gmail.com> (raw)
In-Reply-To: <5368DC74-41CF-4450-AF6F-FFB51EFCCF99@kernel.org>
On Fri, Mar 15, 2024 at 11:24 PM Kees Cook <kees@kernel.org> wrote:
> On March 15, 2024 1:22:39 PM PDT, Paul Moore <paul@paul-moore.com> wrote:
> >On Fri, Mar 15, 2024 at 2:10 PM Christian Göttsche
> ><cgzones@googlemail.com> wrote:
> >>
> >> Add a new hook guarding instantiations of programs with executable
> >> stack. They are being warned about since commit 47a2ebb7f505 ("execve:
> >> warn if process starts with executable stack"). Lets give LSMs the
> >> ability to control their presence on a per application basis.
> >>
> >> Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
> >> ---
> >> fs/exec.c | 4 ++++
> >> include/linux/lsm_hook_defs.h | 1 +
> >> include/linux/security.h | 6 ++++++
> >> security/security.c | 13 +++++++++++++
> >> 4 files changed, 24 insertions(+)
> >
> >Looking at the commit referenced above, I'm guessing the existing
> >security_file_mprotect() hook doesn't catch this?
> >
> >> diff --git a/fs/exec.c b/fs/exec.c
> >> index 8cdd5b2dd09c..e6f9e980c6b1 100644
> >> --- a/fs/exec.c
> >> +++ b/fs/exec.c
> >> @@ -829,6 +829,10 @@ int setup_arg_pages(struct linux_binprm *bprm,
> >> BUG_ON(prev != vma);
> >>
> >> if (unlikely(vm_flags & VM_EXEC)) {
> >> + ret = security_vm_execstack();
> >> + if (ret)
> >> + goto out_unlock;
> >> +
> >> pr_warn_once("process '%pD4' started with executable stack\n",
> >> bprm->file);
> >> }
> >
> >Instead of creating a new LSM hook, have you considered calling the
> >existing security_file_mprotect() hook? The existing LSM controls
> >there may not be a great fit in this case, but I'd like to hear if
> >you've tried that, and if you have, what made you decide a new hook
> >was the better option?
>
> Also, can't MDWE handle this already?
> https://git.kernel.org/linus/b507808ebce23561d4ff8c2aa1fb949fe402bc61
It looks like it, but that doesn't mean there isn't also value in an
associated LSM hook as the LSM hook would admins and security policy
developers/analysts to incorporate this as part of the system's
security policy. It's great that we have all of these cool knobs that
we can play with independent of each other, but sometimes you really
want a single unified security policy that you can look at, analyze,
and reason about.
Regardless, my previous comments still stand, I'd like to hear
verification that the existing security_file_mprotect() hook is not
sufficient, and if its current placement is lacking, why calling it
from a second location wasn't practical and required the creation of a
new LSM hook.
--
paul-moore.com
prev parent reply other threads:[~2024-03-19 23:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-15 18:08 [RFC PATCH 2/2] selinux: wire up new execstack LSM hook Christian Göttsche
2024-03-15 18:08 ` [RFC PATCH 1/2] lsm: introduce new hook security_vm_execstack Christian Göttsche
2024-03-15 18:22 ` Casey Schaufler
2024-03-15 18:30 ` Christian Göttsche
2024-03-15 18:41 ` Casey Schaufler
2024-03-15 20:22 ` Paul Moore
2024-03-16 3:24 ` Kees Cook
2024-03-19 23:10 ` Paul Moore [this message]
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='CAHC9VhTpTbVL4=tchR3Bpcfe0Hsijf5XJ6wsEvU7cu8eUy_iDA@mail.gmail.com' \
--to=paul@paul-moore.com \
--cc=alpic@google.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=brauner@kernel.org \
--cc=casey@schaufler-ca.com \
--cc=cgzones@googlemail.com \
--cc=ebiederm@xmission.com \
--cc=jack@suse.cz \
--cc=jmorris@namei.org \
--cc=john.johansen@canonical.com \
--cc=kamrankhadijadj@gmail.com \
--cc=kees@kernel.org \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=omosnace@redhat.com \
--cc=roberto.sassu@huawei.com \
--cc=serge@hallyn.com \
--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 read-only IMAP folder(s) and NNTP newsgroup(s).