Linux-Integrity Archive on lore.kernel.org
 help / color / Atom feed
From: Nayna <nayna@linux.vnet.ibm.com>
To: Eric Snowberg <eric.snowberg@oracle.com>
Cc: Mimi Zohar <zohar@linux.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: Wed, 12 Feb 2020 09:04:35 -0500
Message-ID: <eae8aa2d-1874-ba72-0452-a55bc811bd3d@linux.vnet.ibm.com> (raw)
In-Reply-To: <0842A02F-3166-4E29-9CC5-9E4C5057E270@oracle.com>


On 2/11/20 12:33 PM, Eric Snowberg wrote:
>> 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.
>
There are two syscalls - init_module, finit_module - and two signature 
verification methods. The problem you are trying to address is the 
finit_module syscall, using both signature verification methods. Why 
enable both signature verification methods ?

If the modules are signed with build time generated keys, use module 
signature verification. If the keys are generated by you and can be 
added to .ima keyring, use IMA policy. The IMA_ARCH_POLICY defines 
secure boot policies at runtime, based on the secure boot state of the 
system. The arch-specific policies defines IMA policy only if the module 
verification is not enabled.

Thanks & Regards,

     - Nayna





  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
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 [this message]
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=eae8aa2d-1874-ba72-0452-a55bc811bd3d@linux.vnet.ibm.com \
    --to=nayna@linux.vnet.ibm.com \
    --cc=bauerman@linux.ibm.com \
    --cc=dhowells@redhat.com \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=eric.snowberg@oracle.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=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

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