On Feb 12, 2020, at 7:04 AM, Nayna [off-list ref] wrote:


On 2/11/20 12:33 PM, Eric Snowberg wrote:

quoted

quoted

On Feb 10, 2020, at 1:33 PM, Mimi Zohar [off-list ref] wrote:

On Mon, 2020-02-10 at 12:24 -0700, Eric Snowberg wrote:

quoted

quoted

On Feb 10, 2020, at 10:09 AM, Mimi Zohar [off-list ref] wrote:

quoted

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 ?

I am enabling both in my patch since a person can turn around and use the other syscall by 
simply compressing their module.  Now their module is verified by a different keyring. 
Other than completely disabling the init_module syscall, which we don’t do, there is nothing 
preventing them from doing that.  We have one kernel config per architecture. We build
and sign the modules with an appended signature.

I can not predict all the ways someone will use a kernel built from this single config.  
I do believe if someone has IMA working with module verification and appended signatures,
some are not going to understand why their module that was compressed and loading 
(via syscall init_module) suddenly fails to load (via syscall finit_module) once they 
uncompress it.