archive mirror
 help / color / mirror / Atom feed
From: Mimi Zohar <>
To: Eric Snowberg <>,
	Nayna <>
Subject: Re: [RFC PATCH 0/2] ima: uncompressed module appraisal support
Date: Fri, 07 Feb 2020 09:51:36 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, 2020-02-06 at 14:40 -0700, Eric Snowberg wrote:


> 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

Enabling CONFIG_IMA_ARCH_POLICY or module.sig_enforce=1 behave totally
differently.  CONFIG_IMA_ARCH_POLICY coordinates between the IMA
signature verification and the original module_sig_check()
verification.  Either one signature verification method is enabled or
the other, but not both.

The existing IMA x86 arch policy has not been updated to support
appended signatures.

To understand what is happening, we need to analyze each scenario

- If CONFIG_MODULE_SIG is configured or enabled on the boot command
line ("module.sig_enforce = 1"), then the IMA arch x86 policy WILL NOT
require an IMA signature.

- If CONFIG_MODULE_SIG is NOT configured or enabled on the boot
command line, then the IMA arch x86 policy WILL require an IMA

- If CONFIG_MODULE_SIG is configured or enabled on the boot command
line, the IMA arch x86 policy is not configured, and the above policy
rule is defined, an appended signature will be verified by both IMA
and module_sig_check().
> If you have a module foo.ko that contains a valid appended signature
> but is not ima signed, it will fail to load.

That would only happen in the second scenario or in the last scenario
if the key is not found.

> Now if the end user simply compresses the same foo.ko, making it
> foo.ko.xz.  The module will load.

This implies that CONFIG_MODULE_SIG is configured or enabled on the
boot command line, like the first scenario described above, or in the
last scenario and the key is found.

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

With the IMA arch x86 policy, without CONFIG_MODULE_SIG configured or
enabled on the boot command line, IMA will prevent the init_module()
syscall.  This is intentional.

Your second patch (2/2) changes the arch x86 policy rule to allow
appended signatures.  The reason for any other changes needs to be
clearer.  I suggest you look at the audit log and kernel messages, as
well as the kexec selftests, to better understand what is happening.


  reply	other threads:[~2020-02-07 14:51 UTC|newest]

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
2020-02-07 14:51     ` Mimi Zohar [this message]
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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [RFC PATCH 0/2] ima: uncompressed module appraisal support' \

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).