linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Snowberg <eric.snowberg@oracle.com>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: Nayna <nayna@linux.vnet.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>
Subject: Re: [RFC PATCH 0/2] ima: uncompressed module appraisal support
Date: Tue, 11 Feb 2020 10:33:25 -0700	[thread overview]
Message-ID: <0842A02F-3166-4E29-9CC5-9E4C5057E270@oracle.com> (raw)
In-Reply-To: <1581366829.5585.898.camel@linux.ibm.com>


> On Feb 10, 2020, at 1:33 PM, Mimi Zohar <zohar@linux.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@linux.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.


  reply	other threads:[~2020-02-11 17:33 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-06 16:42 [RFC PATCH 0/2] ima: uncompressed module appraisal support 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
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 [this message]
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=0842A02F-3166-4E29-9CC5-9E4C5057E270@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=roberto.sassu@huawei.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).