Messages in this thread | | | Subject | Re: [RFC PATCH 0/2] ima: uncompressed module appraisal support | From | Mimi Zohar <> | Date | Mon, 10 Feb 2020 15:33:49 -0500 |
| |
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
| |