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
Subject: Re: [RFC PATCH 0/2] ima: uncompressed module appraisal support
Date: Fri, 7 Feb 2020 10:49:19 -0700 [thread overview]
Message-ID: <764C5FC8-DF0C-4B7A-8B5B-FD8B83F31568@oracle.com> (raw)
In-Reply-To: <1581097201.5585.613.camel@linux.ibm.com>
> On Feb 7, 2020, at 10:40 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>
> On Fri, 2020-02-07 at 09:57 -0700, Eric Snowberg wrote:
>>> On Feb 7, 2020, at 7:51 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>
>>> On Thu, 2020-02-06 at 14:40 -0700, Eric Snowberg wrote:
>>>
>>> <snip>
>>>
>>>> Currently the upstream code will fail if the module is uncompressed.
>>>> If you compress the same module it will load with the current
>>>> upstream code.
>>>>
>>>>> Lastly, there is nothing in these patches that indicate that the
>>>> kernel modules being compressed/uncompressed is related to the
>>>> signature verification.
>>>>>
>>>>
>>>> Basically if you have the following setup:
>>>>
>>>> Kernel built with CONFIG_IMA_ARCH_POLICY or kernel booted with
>>>> module.sig_enforce=1 along with the following ima policy:
>>>>
>>>> appraise func=MODULE_CHECK appraise_type=imasig|modsig
>>>
>>> Enabling CONFIG_IMA_ARCH_POLICY or module.sig_enforce=1 behave totally
>>> differently. CONFIG_IMA_ARCH_POLICY coordinates between the IMA
>>> signature verification and the original module_sig_check()
>>> verification. Either one signature verification method is enabled or
>>> the other, but not both.
>>>
>>> The existing IMA x86 arch policy has not been updated to support
>>> appended signatures.
>>
>> That is not what I’m seeing. Appended signatures mostly work. They just
>> don’t work thru the finit_module system call.
>>
>>> To understand what is happening, we need to analyze each scenario
>>> separately.
>>>
>>> - If CONFIG_MODULE_SIG is configured or enabled on the boot command
>>> line ("module.sig_enforce = 1"), then the IMA arch x86 policy WILL NOT
>>> require an IMA signature.
>>
>> All tests below are without my change
>> x86 booted with module.sig_enforce=1
>>
>> empty ima policy
>
> Sure, in this example the IMA arch x86 policy is not configured and
> there is no custom IMA policy - no IMA.
>
>> $ cat /sys/kernel/security/ima/policy
>
> On a real system, you would want to require a signed IMA policy.
>
>> $ insmod ./foo.ko.xz <— loads ok
>> $ rmmod foo
>> $ unxz ./foo.ko.xz
>> $ insmod ./foo.ko <— loads ok
>> $ rmmod foo
>>
>> add in module appraisal
>
> Sure, the current system
>
>> $ echo "appraise func=MODULE_CHECK appraise_type=imasig|modsig" >
>> /sys/kernel/security/ima/policy
>>
>> $ insmod ./foo.ko.xz <— loads ok
>> $ rmmod foo
>
> Sure, CONFIG_MODULE_SIG is configured or enabled on the boot command
> line ("module.sig_enforce = 1"). IMA won't prevent the init_module()
> syscall.
>
>>
>> $ insmod ./foo.ko
>> insmod: ERROR: could not insert module ./foo.ko: Permission denied
>>
>> last entry from audit log:
>> type=INTEGRITY_DATA msg=audit(1581089373.076:83): pid=2874 uid=0
>> auid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-
>> s0:c0.c1023 op=appraise_data cause=invalid-signature comm="insmod"
>> name="/root/keys/modules/foo.ko" dev="dm-0" ino=10918365
>> res=0^]UID="root" AUID=“root"
>>
>> This is because modsig_verify() will be called from within
>> ima_appraise_measurement(),
>> since try_modsig is true. Then modsig_verify() will return
>> INTEGRITY_FAIL.
>
> Why is it an "invalid signature"? For that you need to look at the
> kernel messages. Most likely it can't find the public key on the .ima
> keyring to verify the signature.
It is invalid because the module has not been ima signed.
next prev parent reply other threads:[~2020-02-07 17:49 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 [this message]
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
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=764C5FC8-DF0C-4B7A-8B5B-FD8B83F31568@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=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).