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]
Message-ID: <5c246616-9a3a-3ed2-c1f9-f634cef511c9@linux.vnet.ibm.com>
Date:   Thu, 6 Feb 2020 15:22:04 -0500
From:   Nayna <nayna@...ux.vnet.ibm.com>
To:     Eric Snowberg <eric.snowberg@...cle.com>,
        dmitry.kasatkin@...il.com, jmorris@...ei.org, serge@...lyn.com
Cc:     zohar@...ux.ibm.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
Subject: Re: [RFC PATCH 0/2] ima: uncompressed module appraisal support


On 2/6/20 11:42 AM, Eric Snowberg wrote:
> When booting with either "ima_policy=secure_boot module.sig_enforce=1"
> or building a kernel with CONFIG_IMA_ARCH_POLICY and booting with
> "ima_policy=secure_boot", module loading behaves differently based on if
> the module is compressed or not.  Originally when appraising a module
> with ima it had to be uncompressed and ima signed.  Recent changes in 5.4
> have allowed internally signed modules to load [1].  But this only works
> if the internally signed module is compressed.  The uncompressed module
> that is internally signed must still be ima signed. This patch series
> tries to bring the two in line.

We (Mimi and I) have been trying to understand the cover letter. It 
seems "by internally signed" you are referring to modules signed with 
build time generated keys.

Our interpretation of the cover letter is that IMA originally did not 
support appended signatures and now does. Since the modules are signed 
with build time generated keys, the signature verification still fails, 
as the keys are only available on the .builtin keyring and not the .ima 
keyring.

Lastly, there is nothing in these patches that indicate that the kernel 
modules being compressed/uncompressed is related to the signature 
verification.

Thanks & Regards,

      - Nayna

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ