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 10.3 \(3273\))
Subject: Re: [RFC PATCH 0/2] ima: uncompressed module appraisal support
From:   Eric Snowberg <eric.snowberg@oracle.com>
In-Reply-To: <1581205431.5585.645.camel@linux.ibm.com>
Date:   Mon, 10 Feb 2020 09:34:42 -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,
        Roberto Sassu <roberto.sassu@huawei.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0F13CB66-6962-44AC-A20D-CCBD82B43625@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>
 <764C5FC8-DF0C-4B7A-8B5B-FD8B83F31568@oracle.com>
 <1581100125.5585.623.camel@linux.ibm.com>
 <992E95D5-D4B9-4913-A36F-BB47631DFE0A@oracle.com>
 <1581101672.5585.628.camel@linux.ibm.com>
 <C25E5885-F00B-48C0-AEF1-FA3014B2FDA6@oracle.com>
 <1581205431.5585.645.camel@linux.ibm.com>
To:     Mimi Zohar <zohar@linux.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Feb 8, 2020, at 4:43 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>=20
> On Fri, 2020-02-07 at 14:38 -0700, Eric Snowberg wrote:
>>> On Feb 7, 2020, at 11:54 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>=20
>>> On Fri, 2020-02-07 at 11:45 -0700, Eric Snowberg wrote:
>>>>=20
>>>>> On Feb 7, 2020, at 11:28 AM, Mimi Zohar <zohar@linux.ibm.com> =
wrote:
>>>>>=20
>>>>> On Fri, 2020-02-07 at 10:49 -0700, Eric Snowberg wrote:
>>>>>>=20
>>>>>>> On Feb 7, 2020, at 10:40 AM, Mimi Zohar <zohar@linux.ibm.com> =
wrote:
>>>>>>>=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.
>>>>>>=20
>>>>>> It is invalid because the module has not been ima signed.=20
>>>>>=20
>>>>> With the IMA policy rule "appraise func=3DMODULE_CHECK
>>>>> appraise_type=3Dimasig|modsig", IMA first tries to verify the IMA
>>>>> signature stored as an xattr and on failure then attempts to =
verify
>>>>> the appended signatures.
>>>>>=20
>>>>> The audit message above indicates that there was a signature, but =
the
>>>>> signature validation failed.
>>>>>=20
>>>>=20
>>>> I do have  CONFIG_IMA_APPRAISE_MODSIG enabled.  I believe the audit =
message above=20
>>>> is coming from modsig_verify in =
security/integrity/ima/ima_appraise.c.
>>>=20
>>> Right, and it's calling:
>>>=20
>>> 	rc =3D integrity_modsig_verify(INTEGRITY_KEYRING_IMA, modsig);
>>>=20
>>> It's failing because it is trying to find the public key on the .ima
>>> keyring.  Make sure that the public needed to validate the kernel
>>> module is on the IMA keyring (eg. keyctl show %keyring:.ima).
>>>=20
>>=20
>> I know that will validate the module properly, but that is not what =
I=E2=80=99m=20
>> trying to solve here. I thought the point of adding =E2=80=9C|modsig=E2=
=80=9D to the
>> ima policy was to tell ima it can either validate against an ima =
keyring OR=20
>> default back to the kernel keyring.  This is what happens with the =
compressed
>> module.  There isn=E2=80=99t anything in the ima keyring to validate =
the compressed
>> modules and it loads when I add =E2=80=9C|modsig=E2=80=9D.
>=20
> "modsig" has nothing to do with keyrings.  The term "modsig" is
> juxtaposed to "imasig".  "modsig" refers to kernel module appended
> signature.=20

Ok, understood, =E2=80=9Cmodsig=E2=80=9D refers to strictly kernel =
module appended signatures
without regard to the keyring that verifies it.  Since there are =
inconsistencies
here, would you consider something like my first patch?  It will verify =
an=20
uncompressed kernel module containing an appended signature  when the =
public key
is contained within the kernel keyring instead of the ima keyring.  Why =
force a=20
person to add the same keys into the ima keyring for validation?  =
Especially when
the kernel keyring is now used to verify appended signatures in the =
compressed
modules.

>=20
>>=20
>> The use case I=E2=80=99m trying to solve is when someone boots with =
ima_policy=3Dsecure_boot.
>=20
> As the secure_boot policy rules are replaced once a custom policy is
> loaded, the "secure_boot" policy should probably be deprecated.  I
> highly recommend using the more recent build time and architecture
> specific run time policy rules, which persist after loading a custom
> policy.=20

I found the secure_boot policy useful, until a custom policy got loaded. =
 But if it
is targeted to be deprecated, I=E2=80=99ll drop my second patch.  I will =
look at the run
time policy rules instead. Thanks.