On Feb 7, 2020, at 10:40 AM, Mimi Zohar [off-list ref] wrote:

On Fri, 2020-02-07 at 09:57 -0700, Eric Snowberg wrote:

quoted

quoted

On Feb 7, 2020, at 7:51 AM, Mimi Zohar [off-list ref] wrote:

On Thu, 2020-02-06 at 14:40 -0700, Eric Snowberg wrote:

<snip>

quoted

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.

quoted

Lastly, there is nothing in these patches that indicate that the

kernel modules being compressed/uncompressed is related to the
signature verification.

quoted

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.

quoted

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.

quoted

$ cat /sys/kernel/security/ima/policy

On a real system, you would want to require a signed IMA policy.

quoted

$ 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 

quoted

$ 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.

quoted

$ 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.