Linux-Integrity Archive on lore.kernel.org
 help / color / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Eric Snowberg <eric.snowberg@oracle.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: Mon, 10 Feb 2020 15:33:49 -0500
Message-ID: <1581366829.5585.898.camel@linux.ibm.com> (raw)
In-Reply-To: <90E53A33-530B-40FB-9982-2818FFD78D73@oracle.com>

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.

Mimi


  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 [this message]
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=1581366829.5585.898.camel@linux.ibm.com \
    --to=zohar@linux.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=nayna@linux.vnet.ibm.com \
    --cc=roberto.sassu@huawei.com \
    --cc=serge@hallyn.com \
    --cc=tglx@linutronix.de \
    /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