LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Casey Schaufler <email@example.com>
To: Mimi Zohar <firstname.lastname@example.org>,
"Eric W. Biederman" <email@example.com>
firstname.lastname@example.org, David Howells <email@example.com>,
"Luis R . Rodriguez" <firstname.lastname@example.org>,
email@example.com, Andres Rodriguez <firstname.lastname@example.org>,
Greg Kroah-Hartman <email@example.com>,
Ard Biesheuvel <firstname.lastname@example.org>,
Kees Cook <email@example.com>,
Stephen Smalley <firstname.lastname@example.org>
Subject: Re: [PATCH v2 3/9] security: define security_kernel_read_blob() wrapper
Date: Fri, 18 May 2018 07:58:55 -0700 [thread overview]
Message-ID: <email@example.com> (raw)
On 5/18/2018 4:30 AM, Mimi Zohar wrote:
> On Thu, 2018-05-17 at 22:37 -0500, Eric W. Biederman wrote:
>> Casey Schaufler <firstname.lastname@example.org> writes:
>>> On 5/17/2018 7:48 AM, Mimi Zohar wrote:
>>>> In order for LSMs and IMA-appraisal to differentiate between the original
>>>> and new syscalls (eg. kexec, kernel modules, firmware), both the original
>>>> and new syscalls must call an LSM hook.
>>>> Commit 2e72d51b4ac3 ("security: introduce kernel_module_from_file hook")
>>>> introduced calling security_kernel_module_from_file() in both the original
>>>> and new syscalls. Commit a1db74209483 ("module: replace
>>>> copy_module_from_fd with kernel version") replaced these LSM calls with
>>>> Commit e40ba6d56b41 ("firmware: replace call to fw_read_file_contents()
>>>> with kernel version") and commit b804defe4297 ("kexec: replace call to
>>>> copy_file_from_fd() with kernel version") replaced their own version of
>>>> reading a file from the kernel with the generic
>>>> kernel_read_file_from_path/fd() versions, which call the pre and post
>>>> security_kernel_read_file LSM hooks.
>>>> Missing are LSM calls in the original kexec syscall and firmware sysfs
>>>> fallback method. From a technical perspective there is no justification
>>>> for defining a new LSM hook, as the existing security_kernel_read_file()
>>>> works just fine. The original syscalls, however, do not read a file, so
>>>> the security hook name is inappropriate. Instead of defining a new LSM
>>>> hook, this patch defines security_kernel_read_blob() as a wrapper for
>>>> the existing LSM security_kernel_file_read() hook.
>>> What a marvelous opportunity to bikeshed!
>>> I really dislike adding another security_ interface just because
>>> the name isn't quite right. Especially a wrapper, which is just
>>> code and execution overhead. Why not change security_kernel_read_file()
>>> to security_kernel_read_blob() everywhere and be done?
>> Nacked-by: "Eric W. Biederman" <email@example.com>
>> Nack on this sharing nonsense. These two interfaces do not share any
>> code in their implementations other than the if statement to distinguish
>> between the two cases.
>> Casey you are wrong. We need something different here.
>> Mimi a wrapper does not cut it. The code is not shared. Despite using
>> a single function call today.
>> If we want comprehensible and maintainable code in the security modules
>> we need to split these two pieces of functionality apart.
> kernel_read_file() is a common, generic method of reading a file from
> the kernel, which is being called from a number of places. The
> kernel_read_file_id enumeration is needed to differentiate between the
> callers. The purpose of the new security_kernel_read_file() calls is
> not for the kernel to read a file, but as a method of identifying the
> original buffer based methods containing a file.
> Having to define a separate LSM hook for each of the original, non
> kernel_read_file(), buffer based method callers, kind of makes sense,
> as the callers themselves are specific, but is it really necessary?
> Could we define a new, generic LSM hook named
> security_kernel_buffer_data() for this purpose?
If there are two disparate behaviors wrapped into kernel_read_file()
Eric (bless him) is right. It should be broken into two hooks. I think
that if we look (too) carefully we'll find other places where hooks
should get broken up, or combined*. My question is just how important
is it that this gets changed?
* calling security_inode_secid() and then immediately
security_secid_to_secctx() grates on my sensibilities.
next prev parent reply other threads:[~2018-05-18 14:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-17 14:48 [PATCH v2 0/9] kexec/firmware: support system wide policy requiring signatures Mimi Zohar
2018-05-17 14:48 ` [PATCH v2 1/9] ima: based on policy verify firmware signatures (pre-allocated buffer) Mimi Zohar
2018-05-17 14:48 ` [PATCH v2 2/9] ima: fix updating the ima_appraise flag Mimi Zohar
2018-05-17 14:48 ` [PATCH v2 3/9] security: define security_kernel_read_blob() wrapper Mimi Zohar
2018-05-18 0:24 ` Casey Schaufler
2018-05-18 3:37 ` Eric W. Biederman
2018-05-18 11:30 ` Mimi Zohar
2018-05-18 14:58 ` Casey Schaufler [this message]
2018-05-18 15:29 ` Mimi Zohar
2018-05-18 17:13 ` James Morris
2018-05-18 17:55 ` Mimi Zohar
2018-05-17 14:48 ` [PATCH v2 4/9] kexec: add call to LSM hook in original kexec_load syscall Mimi Zohar
2018-05-17 14:48 ` [PATCH v2 5/9] ima: based on policy require signed kexec kernel images Mimi Zohar
2018-05-17 14:48 ` [PATCH v2 6/9] firmware: add call to LSM hook before firmware sysfs fallback Mimi Zohar
2018-05-17 14:48 ` [PATCH v2 7/9] ima: based on policy require signed firmware (sysfs fallback) Mimi Zohar
2018-05-17 14:48 ` [PATCH v2 8/9] ima: add build time policy Mimi Zohar
2018-05-17 14:48 ` [PATCH v2 9/9] ima: based on policy prevent loading firmware (pre-allocated buffer) Mimi Zohar
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH v2 3/9] security: define security_kernel_read_blob() wrapper' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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 NNTP newsgroup(s).