Linux-Integrity Archive on lore.kernel.org
 help / color / Atom feed
From: Eric Snowberg <eric.snowberg@oracle.com>
To: Nayna <nayna@linux.vnet.ibm.com>
Cc: dmitry.kasatkin@gmail.com, jmorris@namei.org, serge@hallyn.com,
	Mimi Zohar <zohar@linux.ibm.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,
	Eric Snowberg <eric.snowberg@oracle.com>,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/2] ima: uncompressed module appraisal support
Date: Thu, 6 Feb 2020 14:40:40 -0700
Message-ID: <09D68C13-75E2-4BD6-B4E6-F765B175C7FD@oracle.com> (raw)
In-Reply-To: <5c246616-9a3a-3ed2-c1f9-f634cef511c9@linux.vnet.ibm.com>


> On Feb 6, 2020, at 1:22 PM, Nayna <nayna@linux.vnet.ibm.com> wrote:
> 
> 
> 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.

I am referring to any module that includes an appended signature.  They could be signed at build time or anytime afterwards using /usr/src/kernels/$(uname -r)/scripts/sign-file.  As long as the public key is contained in the builtin kernel trusted keyring.


> Our interpretation of the cover letter is that IMA originally did not support appended signatures and now does.

Correct, before the changes added to 5.4 [1], it was not possible to have a digital signature based appraisal policy that worked with a compressed module.  This is because you can’t ima sign a compressed module, since the signature would be lost by the time it gets to the init_module syscall.  With the changes in [1] you can, if you include “modsig” to your policy, which allows the appended module to be checked instead.


> 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.

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.

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

Basically if you have the following setup:

Kernel built with CONFIG_IMA_ARCH_POLICY or kernel booted with module.sig_enforce=1 along with the following ima policy:

appraise func=MODULE_CHECK appraise_type=imasig|modsig

If you have a module foo.ko that contains a valid appended signature but is not ima signed, it will fail to load.  Now if the enduser simply compresses the same foo.ko, making it foo.ko.xz.  The module will load.

Modules can be loaded thru two different syscalls, finit_module and init_module.  The changes added in [1] work if you use the init_module syscall.  My change adds support when the finit_module syscall gets used instead.


[1] https://patchwork.kernel.org/cover/10986023


  reply index

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-06 16:42 Eric Snowberg
2020-02-06 16:42 ` [RFC PATCH 1/2] ima: Implement support for uncompressed module appended signatures Eric Snowberg
2020-02-06 17:07   ` Lakshmi Ramasubramanian
2020-02-06 17:30     ` Eric Snowberg
2020-02-06 18:05   ` Mimi Zohar
2020-02-06 19:01     ` Eric Snowberg
2020-02-06 19:10       ` Mimi Zohar
2020-02-06 16:42 ` [RFC PATCH 2/2] ima: Change default secure_boot policy to include " Eric Snowberg
2020-02-06 20:22 ` [RFC PATCH 0/2] ima: uncompressed module appraisal support Nayna
2020-02-06 21:40   ` Eric Snowberg [this message]
2020-02-07 14:51     ` Mimi Zohar
2020-02-07 16:57       ` Eric Snowberg
2020-02-07 17:40         ` Mimi Zohar
2020-02-07 17:49           ` Eric Snowberg
2020-02-07 18:28             ` Mimi Zohar
2020-02-07 18:45               ` Eric Snowberg
2020-02-07 18:54                 ` Mimi Zohar
2020-02-07 21:38                   ` Eric Snowberg
2020-02-08 23:43                     ` Mimi Zohar
2020-02-10 16:34                       ` Eric Snowberg
2020-02-10 17:09                         ` Mimi Zohar
2020-02-10 19:24                           ` Eric Snowberg
2020-02-10 20:33                             ` Mimi Zohar
2020-02-11 17:33                               ` Eric Snowberg
2020-02-12 14:04                                 ` Nayna
2020-02-13 15:32                                   ` Eric Snowberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=09D68C13-75E2-4BD6-B4E6-F765B175C7FD@oracle.com \
    --to=eric.snowberg@oracle.com \
    --cc=bauerman@linux.ibm.com \
    --cc=dhowells@redhat.com \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jmorris@namei.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=nayna@linux.ibm.com \
    --cc=nayna@linux.vnet.ibm.com \
    --cc=serge@hallyn.com \
    --cc=tglx@linutronix.de \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Integrity Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-integrity/0 linux-integrity/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-integrity linux-integrity/ https://lore.kernel.org/linux-integrity \
		linux-integrity@vger.kernel.org
	public-inbox-index linux-integrity

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-integrity


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git