Signed kernel modules

A digital signature is a method of verifying the authenticity of digital data. A valid digital signature can be used to reason that the ‘signed’ content was created by a known sender and that the data was not modified between the time of signing and its current state.

Kernel modules are organized, functional sections of code that can be loaded and removed from the kernel on demand. A module provides additional functionality of the kernel without the need to reboot the system or recompile the code.

A signed kernel module is a kernel module with a digitial signature that validates the contents of the module along with the attached signature belongs to a trusted party in the systems ‘key chain’.

Each kernel module is signed with a industry standard PKCS#7 standard (https://tools.ietf.org/html/rfc5652). Modules that are built when the kernel is compiled by the operating system vendor are signed at build time, with the ‘hash’ specified at build time by the directive CONFIG_MODULE_SIG_HASH. Each module can only be signed once by a dsingle signer, additional signatures are ignored. The signature is appended to the file along with the string “~Module signature appended~” at the end of the file. This allows for easy confirmation of the signing process by using the ‘strings’ tool to find the above string in an uncompressed kernel module.

$ strings ecryptfs.ko | tail -n 1
~Module signature appended~

This signature in the file is consulted by the kernel and validated during the module loading process. The number of cryptographic hash algorithms has increased over time, a module can be signed by a single algorithm.

The supported hash algorithms for a release can be found in the kernels build configuration file, along with other signing related options.

$ grep CONFIG_MODULE_SIG_HASH  ~/rhel-8-kernel/redhat/configs/*config
| sort| uniq
CONFIG_MODULE_SIG_HASH="sha256"

From this you can see that Red Hat Enterprise Linux 8 defaults to sha256 and only supports sha256 signed kernel modules. These options are used at build time and runtime of the kernel that is being built. When the kernel is built the key used to sign the modules is compiled into the kernel (the vmlinuz) file for use when validating module signatures.

The kernel has two entry paths of loading a module. The init\_module() function was the traditional path

These system call functions are: init\_module() and finit\_module(). They both perform the same essential function, finit takes an FD instead of a path to the module.

[This may be useful if you have some kind of selinux policy on loading modules that are labeled ?]

An overview of the function calls in the 'useful' codepath.

init_module() 
 -> load_module() 
  -> module_sig_check()  <-- checks to see if it has a sig
    -> mod_verify_sig()   <--- verify the signature.
      -> verify_pkcs7_signature() <-- chcks to see if its valid pkcs7
       -> pkcs7_verify_one()  <- checks a single signature (from the list)
        -> public_key_verify_signature() <- actual crypto done here.

There is provision for the secondary keychain (The comments here don't seem to match the actual code), this is changed in later versions.

mod_verify_sig() {

        /*
      * Check signature using built-in trusted keys and, if configured,
      * secondary trusted keys.
      */
     err =  verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len,
                                   VERIFY_USE_SECONDARY_KEYRING,
                                   VERIFYING_MODULE_SIGNATURE,
                                   NULL, NULL);
     if (IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING) && err) {
             /*
              * Check signature using platform trusted keys. This does
              * not consider the built-in keys, so must be done separately
              * from above, if possible and necessary.
              */
             err =  verify_pkcs7_signature(mod, modlen, mod + modlen,
                                           sig_len,
                                           VERIFY_USE_PLATFORM_KEYRING,
                                           VERIFYING_MODULE_SIGNATURE,
                                           NULL, NULL);
     }
     return err;


}

From initial research this appears to be the ".builtin\_trusted\_keys" keyring. But the Secondary keyring can also be built if configured at build time. (This is not the case in RHEL systems).

This secondary keychain must also be trusted by a signer in the primary keychain, so.. its not simple.

Listing the primary keys:

# keyctl list %:.builtin_trusted_keys 

These keys will only show when booted in secureboot mode with secureboot in a reputable state.

The kernel module signature check 'fails closed' leaving it up to the admin controlled parameter to decide on the behavior.

This is on the decided in module\_sig\_check:

static int module_sig_check(struct load_info *info, int flags) {

  err = mod_verify_sig(mod, info);

  switch(err) {

    case 0: /* module okay to load */
       return 0;

    case -ENODATA: /* Loading of unsigned module */
       goto decide;

    case -ENOPKG:  /* Unknown crypto on module */
       goto decide;

    case -ENOKEY:  /* unavailable key (not in current chain */
       goto decide;

    decide:
      if (is_module_sig_enforced()) {
                pr_notice("%s: %s is rejected\n", info->name, reason);
                return -EKEYREJECTED;
      }

      return security_locked_down(LOCKDOWN_MODULE_SIGNATURE);

      /* All other errors are fatal, including nomem, unparseable */

    default:
      return err;

  }
}  

The code also heavily defaults to the 'lockdown' mode state.

If the system is not UEFI-based or if UEFI Secure Boot is not enabled, then only the keys that are embedded in the kernel are loaded onto the system key ring and you have no ability to augment that set of keys without rebuilding the kernel and signing all kernel modules with your own key.

However, if you do have secureboot as an option.

Secureboot has a provision for adding 'additional' keys to the 'platform' keyring, it uses a Machine Owner Key (MOK) to add additional keys to the UEFI secure boot database, adding them to 'system' keyring for use.

The Red Hat Enterprise Linux boot process uses the shim.efi, MokManager.efi, grubx64.efi and each of these supports the "MOK" style keyring addition.

Once a key has been added to generated and added to the via mokutil, on the next reboot the user will required to input a passphrase at the physical console (the same that was generated when the key was created).

This allows local users to be able to add keys to the system keychain that are able to be used to validate signatures of kernel modules.

Create a file configuration\_file.config with the following contents, modifying O and CN options.

[ req ]
default_bits = 4096
distinguished_name = req_distinguished_name
prompt = no
string_mask = utf8only
x509_extensions = myexts

[ req_distinguished_name ]
O = Organization
CN = Organization signing key
emailAddress = E-mail address

[ myexts ]
basicConstraints=critical,CA:FALSE
keyUsage=digitalSignature
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid
EOF

From this file use openssl to generate a public and private key pairs which can be used to sign the kernel module and also enrolled in the systems "MOK" keychain.

# openssl req -x509 -new -nodes -utf8 -sha256 -days 36500 -batch -config configuration_file.config -outform DER  -out public_key.der \ > -keyout  private_key.priv

The openssl command should create two files, public\_key.der and private\_key.priv.

# mokutil --import public_key.der

You will be asked to enter and confirm a password for this MOK enrollment request.

Reboot the machine.

The shim.efi will notice that there is a pending MOK enrollment and start MokManager.efi to complete the enrollment. The password used during the certificate generation process will need to be entered at the console during the early-boot stage to confirm that this key is to be enrolled.

This public key will now be in the MOK list and be added to the system key ring on all future boots (until cleared) while secureboot is enabled.

For example the "Wades own very special kmod v01" singing key:

# keyctl list %:.system_keyring
6 keys in keyring:
...asymmetric: Red Hat Enterprise Linux Driver Update Program (key 3): bf57f3e87...

...asymmetric: Red Hat Secure Boot (CA key 1): 4016841644ce3a810408050766e8f8a29...
...asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed...
...asymmetric: Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e...
...asymmetric: Red Hat Enterprise Linux kernel signing key: 4249689eefc77e95880b...
...asymmetric: Red Hat Enterprise Linux kpatch signing key: 4d38fd864ebe18c5f0b7...
...asymmetric: Wades own very special kmod v01 signing key: c4ae92e16da94228cd9e...

Before the module can be loaded it must be signed, there is a sign-file script included in the kernel source ./scripts/ directory which provides compatible a compatible signing technique that is able to be used for 'out of tree' built kernel modules. An example of singing my\_module

perl /usr/src/kernels/$(uname -r)/scripts/sign-file sha256 private_key.priv public_key.der my_module.ko

After the signature has been applied, the modinfo command should show the newly applied signature in its output.

Note: The signing process does not need to be on the machine where the module will be loaded. Module signing keys should be adequately secured with best practices for public/private keys.

Red Hat Guide for secure boot

Adding a secondary sign to out of tree kernel module

Kernel security subsystem (keyring section)

Secondary trusted keyring ( SECONDARY_TRUSTED_KEYRING )