Re: [RFC PATCH 0/2] ima: uncompressed module appraisal support

[Mimi Zohar]

On Mon, 2020-02-10 at 12:24 -0700, Eric Snowberg wrote:
> > On Feb 10, 2020, at 10:09 AM, Mimi Zohar <zohar@xxxxxxxxxxxxx> 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