linux-kernel - Re: [RFC PATCH 0/2] ima: uncompressed module appraisal support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 11 Feb 2020 10:33:25 -0700
From:   Eric Snowberg <eric.snowberg@...cle.com>
To:     Mimi Zohar <zohar@...ux.ibm.com>
Cc:     Nayna <nayna@...ux.vnet.ibm.com>, dmitry.kasatkin@...il.com,
        jmorris@...ei.org, serge@...lyn.com, dhowells@...hat.com,
        geert@...ux-m68k.org, gregkh@...uxfoundation.org,
        nayna@...ux.ibm.com, tglx@...utronix.de, bauerman@...ux.ibm.com,
        mpe@...erman.id.au, linux-integrity@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Roberto Sassu <roberto.sassu@...wei.com>
Subject: Re: [RFC PATCH 0/2] ima: uncompressed module appraisal support


> On Feb 10, 2020, at 1:33 PM, Mimi Zohar <zohar@...ux.ibm.com> wrote:
> 
> On Mon, 2020-02-10 at 12:24 -0700, Eric Snowberg wrote:
>>> On Feb 10, 2020, at 10:09 AM, Mimi Zohar <zohar@...ux.ibm.com> wrote:
> 
>>>> 
>>>> Ok, understood, “modsig” 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.
>>> 
>> 
>> 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.

What if I change this part of my patch from

+       if (rc && func == MODULE_CHECK)

to

+       sig_enforce = is_module_sig_enforced();
+       if (sig_enforce && rc && func == MODULE_CHECK)

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.