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 [thread overview]
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
next prev parent reply other threads:[~2020-02-10 20:34 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 [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
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).