From: Eric Snowberg <eric.snowberg@oracle.com>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: Nayna <nayna@linux.vnet.ibm.com>,
dmitry.kasatkin@gmail.com, jmorris@namei.org, serge@hallyn.com,
dhowells@redhat.com, geert@linux-m68k.org,
gregkh@linuxfoundation.org, nayna@linux.ibm.com,
tglx@linutronix.de, bauerman@linux.ibm.com, mpe@ellerman.id.au,
linux-integrity@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org,
Roberto Sassu <roberto.sassu@huawei.com>
Subject: Re: [RFC PATCH 0/2] ima: uncompressed module appraisal support
Date: Tue, 11 Feb 2020 10:33:25 -0700 [thread overview]
Message-ID: <0842A02F-3166-4E29-9CC5-9E4C5057E270@oracle.com> (raw)
In-Reply-To: <1581366829.5585.898.camel@linux.ibm.com>
> On Feb 10, 2020, at 1:33 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>
> On Mon, 2020-02-10 at 12:24 -0700, Eric Snowberg wrote:
>>> On Feb 10, 2020, at 10:09 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>
>>>>
>>>> Ok, understood, “modsig” refers to strictly kernel module appended signatures
>>>> without regard to the keyring that verifies it. Since there are inconsistencies
>>>> here, would you consider something like my first patch? It will verify an
>>>> uncompressed kernel module containing an appended signature when the public key
>>>> is contained within the kernel keyring instead of the ima keyring. Why force a
>>>> person to add the same keys into the ima keyring for validation? Especially when
>>>> the kernel keyring is now used to verify appended signatures in the compressed
>>>> modules.
>>>
>>> Different use case scenarios have different requirements. Suppose for
>>> example that the group creating the kernel image is not the same as
>>> using it. The group using the kernel image could sign all files,
>>> including kernel modules (imasig), with their own private key. Only
>>> files that they signed would be permitted. Your proposal would break
>>> the current expectations, allowing kernel modules signed by someone
>>> else to be loaded.
>>>
>>
>> All the end user needs to do is compress any module created by the group that built
>> the original kernel image to work around the scenario above. Then the appended
>> signature in the compressed module will be verified by the kernel keyring. Does
>> this mean there is a security problem that should be fixed, if this is a concern?
>
> Again, the issue isn't compressed/uncompressed kernel modules, but the
> syscall used to load the kernel module. IMA can prevent using the the
> init_module syscall. Refer to the ima_load_data() LOADING_MODULE
> case.
Within the ima_load_data() LOADING_MODULE case, to prevent IMA from using
the init_module syscall, is_module_sig_enforced() must return false. Currently
when is_module_sig_enforced() returns true, the kernel keyring is always used
for verification.
What if I change this part of my patch from
+ if (rc && func == MODULE_CHECK)
to
+ sig_enforce = is_module_sig_enforced();
+ if (sig_enforce && rc && func == MODULE_CHECK)
Now when the init_module syscall is available, finit_module syscall will use
both the ima keyring and kernel keyring for verification. When the
init_module syscall is blocked from use, the finit_module syscall will only use
the ima keyring for validation. I believe this would satisfy both your use
case and mine.
next prev parent reply other threads:[~2020-02-11 17:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-06 16:42 [RFC PATCH 0/2] ima: uncompressed module appraisal support Eric Snowberg
2020-02-06 16:42 ` [RFC PATCH 1/2] ima: Implement support for uncompressed module appended signatures Eric Snowberg
2020-02-06 17:07 ` Lakshmi Ramasubramanian
2020-02-06 17:30 ` Eric Snowberg
2020-02-06 18:05 ` Mimi Zohar
2020-02-06 19:01 ` Eric Snowberg
2020-02-06 19:10 ` Mimi Zohar
2020-02-06 16:42 ` [RFC PATCH 2/2] ima: Change default secure_boot policy to include " Eric Snowberg
2020-02-06 20:22 ` [RFC PATCH 0/2] ima: uncompressed module appraisal support Nayna
2020-02-06 21:40 ` Eric Snowberg
2020-02-07 14:51 ` Mimi Zohar
2020-02-07 16:57 ` Eric Snowberg
2020-02-07 17:40 ` Mimi Zohar
2020-02-07 17:49 ` Eric Snowberg
2020-02-07 18:28 ` Mimi Zohar
2020-02-07 18:45 ` Eric Snowberg
2020-02-07 18:54 ` Mimi Zohar
2020-02-07 21:38 ` Eric Snowberg
2020-02-08 23:43 ` Mimi Zohar
2020-02-10 16:34 ` Eric Snowberg
2020-02-10 17:09 ` Mimi Zohar
2020-02-10 19:24 ` Eric Snowberg
2020-02-10 20:33 ` Mimi Zohar
2020-02-11 17:33 ` Eric Snowberg [this message]
2020-02-12 14:04 ` Nayna
2020-02-13 15:32 ` Eric Snowberg
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=0842A02F-3166-4E29-9CC5-9E4C5057E270@oracle.com \
--to=eric.snowberg@oracle.com \
--cc=bauerman@linux.ibm.com \
--cc=dhowells@redhat.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=jmorris@namei.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mpe@ellerman.id.au \
--cc=nayna@linux.ibm.com \
--cc=nayna@linux.vnet.ibm.com \
--cc=roberto.sassu@huawei.com \
--cc=serge@hallyn.com \
--cc=tglx@linutronix.de \
--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 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).