From: Kees Cook <keescook@chromium.org>
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Paul Moore <paul@paul-moore.com>,
James Morris <jmorris@namei.org>,
linux-security-module@vger.kernel.org,
Mimi Zohar <zohar@linux.ibm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH] LoadPin: Ignore the "contents" argument of the LSM hooks
Date: Tue, 13 Dec 2022 20:06:55 -0800 [thread overview]
Message-ID: <202212132006.F29BB81A@keescook> (raw)
In-Reply-To: <20221212211319.GA15511@mail.hallyn.com>
On Mon, Dec 12, 2022 at 03:13:19PM -0600, Serge E. Hallyn wrote:
> On Fri, Dec 09, 2022 at 11:54:57AM -0800, Kees Cook wrote:
> > LoadPin only enforces the read-only origin of kernel file reads. Whether
> > or not it was a partial read isn't important. Remove the overly
> > conservative checks so that things like partial firmware reads will
> > succeed (i.e. reading a firmware header).
> >
> > Fixes: 2039bda1fa8d ("LSM: Add "contents" flag to kernel_read_file hook")
> > Cc: Paul Moore <paul@paul-moore.com>
> > Cc: James Morris <jmorris@namei.org>
> > Cc: "Serge E. Hallyn" <serge@hallyn.com>
>
> Acked-by: Serge Hallyn <serge@hallyn.com>
>
> Seems reasonable.
Thanks!
> So the patch which introduced this was
> 2039bda1f: LSM: Add "contents" flag to kernel_read_file hook
> It sounds like the usage of @contents which it added to ima still
> makes sense. But what about the selinux_kernel_read_file() one?
I think those continue to make sense since those LSM may be sensitive to
the _content_ (rather than the _origin_) of the file.
-Kees
--
Kees Cook
next prev parent reply other threads:[~2022-12-14 4:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-09 19:54 [PATCH] LoadPin: Ignore the "contents" argument of the LSM hooks Kees Cook
2022-12-12 21:13 ` Serge E. Hallyn
2022-12-14 4:06 ` Kees Cook [this message]
2022-12-15 20:16 ` Paul Moore
2022-12-14 4:06 ` Kees Cook
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=202212132006.F29BB81A@keescook \
--to=keescook@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=jmorris@namei.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.com \
--cc=zohar@linux.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.