> On Feb 7, 2020, at 11:28 AM, Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > On Fri, 2020-02-07 at 10:49 -0700, Eric Snowberg wrote: >> >>> On Feb 7, 2020, at 10:40 AM, Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: >>> >>>> $ 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. > > With the IMA policy rule "appraise func=MODULE_CHECK > appraise_type=imasig|modsig", IMA first tries to verify the IMA > signature stored as an xattr and on failure then attempts to verify > the appended signatures. > > The audit message above indicates that there was a signature, but the > signature validation failed. > I do have CONFIG_IMA_APPRAISE_MODSIG enabled. I believe the audit message above is coming from modsig_verify in security/integrity/ima/ima_appraise.c.
