Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: [RFC PATCH 0/2] ima: uncompressed module appraisal support
From:   Eric Snowberg <eric.snowberg@oracle.com>
In-Reply-To: <1581097201.5585.613.camel@linux.ibm.com>
Date:   Fri, 7 Feb 2020 10:49:19 -0700
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
Content-Transfer-Encoding: quoted-printable
Message-Id: <764C5FC8-DF0C-4B7A-8B5B-FD8B83F31568@oracle.com>
References: <20200206164226.24875-1-eric.snowberg@oracle.com>
 <5c246616-9a3a-3ed2-c1f9-f634cef511c9@linux.vnet.ibm.com>
 <09D68C13-75E2-4BD6-B4E6-F765B175C7FD@oracle.com>
 <1581087096.5585.597.camel@linux.ibm.com>
 <330BDFAC-E778-4E9D-A2D2-DD81B745F6AB@oracle.com>
 <1581097201.5585.613.camel@linux.ibm.com>
To:     Mimi Zohar <zohar@linux.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Feb 7, 2020, at 10:40 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>=20
> 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:
>>>=20
>>> On Thu, 2020-02-06 at 14:40 -0700, Eric Snowberg wrote:
>>>=20
>>> <snip>
>>>=20
>>>> 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.
>>>>=20
>>>>> Lastly, there is nothing in these patches that indicate that the
>>>> kernel modules being compressed/uncompressed is related to the
>>>> signature verification.
>>>>>=20
>>>>=20
>>>> Basically if you have the following setup:
>>>>=20
>>>> Kernel built with CONFIG_IMA_ARCH_POLICY or kernel booted with
>>>> module.sig_enforce=3D1 along with the following ima policy:
>>>>=20
>>>> appraise func=3DMODULE_CHECK appraise_type=3Dimasig|modsig
>>>=20
>>> Enabling CONFIG_IMA_ARCH_POLICY or module.sig_enforce=3D1 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.
>>>=20
>>> The existing IMA x86 arch policy has not been updated to support
>>> appended signatures.
>>=20
>> That is not what I=E2=80=99m seeing.  Appended signatures mostly =
work.  They just
>> don=E2=80=99t work thru the finit_module system call.
>>=20
>>> To understand what is happening, we need to analyze each scenario
>>> separately.
>>>=20
>>> - If CONFIG_MODULE_SIG is configured or enabled on the boot command
>>> line ("module.sig_enforce =3D 1"), then the IMA arch x86 policy WILL =
NOT
>>> require an IMA signature.
>>=20
>> All tests below are without my change
>> x86 booted with module.sig_enforce=3D1
>>=20
>> empty ima policy
>=20
> Sure, in this example the IMA arch x86 policy is not configured and
> there is no custom IMA policy - no IMA.
>=20
>> $ cat /sys/kernel/security/ima/policy
>=20
> On a real system, you would want to require a signed IMA policy.
>=20
>> $ insmod ./foo.ko.xz   <=E2=80=94 loads ok
>> $ rmmod foo
>> $ unxz ./foo.ko.xz
>> $ insmod ./foo.ko      <=E2=80=94 loads ok
>> $ rmmod foo
>>=20
>> add in module appraisal=20
>=20
> Sure, the current system=20
>=20
>> $ echo "appraise func=3DMODULE_CHECK appraise_type=3Dimasig|modsig" >
>> /sys/kernel/security/ima/policy
>>=20
>> $ insmod ./foo.ko.xz   <=E2=80=94 loads ok
>> $ rmmod foo
>=20
> Sure, CONFIG_MODULE_SIG is configured or enabled on the boot command
> line ("module.sig_enforce =3D 1").  IMA won't prevent the =
init_module()
> syscall.
>=20
>>=20
>> $ insmod ./foo.ko
>> insmod: ERROR: could not insert module ./foo.ko: Permission denied
>>=20
>> last entry from audit log:
>> type=3DINTEGRITY_DATA msg=3Daudit(1581089373.076:83): pid=3D2874 =
uid=3D0
>> auid=3D0 ses=3D1 subj=3Dunconfined_u:unconfined_r:unconfined_t:s0-
>> s0:c0.c1023 op=3Dappraise_data cause=3Dinvalid-signature =
comm=3D"insmod"
>> name=3D"/root/keys/modules/foo.ko" dev=3D"dm-0" ino=3D10918365
>> res=3D0^]UID=3D"root" AUID=3D=E2=80=9Croot"
>>=20
>> This is because modsig_verify() will be called from within
>> ima_appraise_measurement(),=20
>> since try_modsig is true.  Then modsig_verify() will return
>> INTEGRITY_FAIL.
>=20
> 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.=20