[RFC PATCH 0/2] ima: uncompressed module appraisal support

[Eric Snowberg]

> On Feb 7, 2020, at 10:40 AM, Mimi Zohar <zohar at 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 at 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.