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: <eae8aa2d-1874-ba72-0452-a55bc811bd3d@linux.vnet.ibm.com>
Date:   Thu, 13 Feb 2020 08:32:33 -0700
Cc:     Mimi Zohar <zohar@linux.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: <A0B7848D-519A-4A81-BFC2-DC86CA995CFD@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>
 <0F13CB66-6962-44AC-A20D-CCBD82B43625@oracle.com>
 <1581354556.5585.827.camel@linux.ibm.com>
 <90E53A33-530B-40FB-9982-2818FFD78D73@oracle.com>
 <1581366829.5585.898.camel@linux.ibm.com>
 <0842A02F-3166-4E29-9CC5-9E4C5057E270@oracle.com>
 <eae8aa2d-1874-ba72-0452-a55bc811bd3d@linux.vnet.ibm.com>
To:     Nayna <nayna@linux.vnet.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Feb 12, 2020, at 7:04 AM, Nayna <nayna@linux.vnet.ibm.com> wrote:
>=20
>=20
> On 2/11/20 12:33 PM, Eric Snowberg wrote:
>>> On Feb 10, 2020, at 1:33 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>=20
>>> On Mon, 2020-02-10 at 12:24 -0700, Eric Snowberg wrote:
>>>>> On Feb 10, 2020, at 10:09 AM, Mimi Zohar <zohar@linux.ibm.com> =
wrote:
>>>>>> 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
>>>>>> 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
>>>>>> 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.
>>>>> Different use case scenarios have different requirements.  Suppose =
for
>>>>> example that the group creating the kernel image is not the same =
as
>>>>> using it.  The group using the kernel image could sign all files,
>>>>> including kernel modules (imasig), with their own private key. =
Only
>>>>> files that they signed would be permitted.  Your proposal would =
break
>>>>> the current expectations, allowing kernel modules signed by =
someone
>>>>> else to be loaded.
>>>>>=20
>>>> All the end user needs to do is compress any module created by the =
group that built
>>>> the original kernel image to work around the scenario above.  Then =
the appended
>>>> signature in the compressed module will be verified by the kernel =
keyring. Does
>>>> this mean there is a security problem that should be fixed, if this =
is a concern?
>>> Again, the issue isn't compressed/uncompressed kernel modules, but =
the
>>> syscall used to load the kernel module.  IMA can prevent using the =
the
>>> init_module syscall.  Refer to the ima_load_data() LOADING_MODULE
>>> case.
>> Within the ima_load_data() LOADING_MODULE case, to prevent IMA from =
using
>> the init_module syscall, is_module_sig_enforced() must return false. =
Currently
>> when is_module_sig_enforced() returns true, the kernel keyring is =
always used
>> for verification.
>>=20
>> What if I change this part of my patch from
>>=20
>> +       if (rc && func =3D=3D MODULE_CHECK)
>>=20
>> to
>>=20
>> +       sig_enforce =3D is_module_sig_enforced();
>> +       if (sig_enforce && rc && func =3D=3D MODULE_CHECK)
>>=20
>> Now when the init_module syscall is available, finit_module syscall =
will use
>> both the ima keyring and kernel keyring for verification.  When the
>> init_module syscall is blocked from use, the finit_module syscall =
will only use
>> the ima keyring for validation.  I believe this would satisfy both =
your use
>> case and mine.
>>=20
> There are two syscalls - init_module, finit_module - and two signature =
verification methods. The problem you are trying to address is the =
finit_module syscall, using both signature verification methods. Why =
enable both signature verification methods ?

I am enabling both in my patch since a person can turn around and use =
the other syscall by=20
simply compressing their module.  Now their module is verified by a =
different keyring.=20
Other than completely disabling the init_module syscall, which we =
don=E2=80=99t do, there is nothing=20
preventing them from doing that.  We have one kernel config per =
architecture. We build
and sign the modules with an appended signature.

I can not predict all the ways someone will use a kernel built from this =
single config. =20
I do believe if someone has IMA working with module verification and =
appended signatures,
some are not going to understand why their module that was compressed =
and loading=20
(via syscall init_module) suddenly fails to load (via syscall =
finit_module) once they=20
uncompress it. =20