IMA and EVM Concepts

The Linux runtime Integrity Measurement Architecture (IMA) calculates hash values of executables and other sensitive system files. The hash value is used in multiple ways:

  • stored in a measurement log

  • used for verifying signatures

  • stored in the system audit log

The hash algorithm is defined by CONFIG_IMA_DEFAULT_HASH, which can be overridden by the Boot Command Line Arguments ima_hash specifier.

IMA Measurement maintains an aggregate integrity value over the measurement log if the platform has a TPM chip. The TPM can attest to the state of these system files. It typically uses PCR 10. The TPM attestation quote is a signature over the PCR, indirectly providing integrity over the measurement log.

The measurement system requires both a TPM and an independent verifier.

Measurement is similar to the pre-OS trusted boot concept.

IMA keeps a table of the hash values. If the hash is seen again, the contents are not measured again. CONFIG_IMA_DISABLE_HTABLE offers other options.

IMA Appraisal can check the file’s digital signature or hash and take action if the signature verification fails.

Appraisal is similar to the pre-OS secure boot concept.

The appraisal system is local, and requires neither a TPM nor a separate verifier.

IMA Audit includes the file hash in the system’s audit log. This can be useful for analytics and forensics.

Threat Model

Warning

Under construction.

IMA detects an attempt to access an invalid item. The TPM provides cryptographic integrity over the measurement log, which can be reported to a verifier. It covers threats such as:

  • Unsigned software.

  • Software signed with an unknown or revoked key.

  • Software that has been altered after signing.

The measurement log verifier can further detect:

  • Running unapproved software.

  • Running approved but back level software.

  • A file with an unexpected file name.

These attacks are not in scope:

Memory Attacks

IMA measures and appraises items when they are first accessed. An attack that modifies memory after the access will not be detected.

Examples:

  • A run-time alteration of memory, such as an mmap’ed file.

  • An alteration of the appraise flag to disable appraisal.

File Name Changes

IMA does not appraise the file name, which is associated with the directory, not the file meta-data.

For example, an the executable renamed from mv renamed to rm will still pass appraisal. The file name will be measured.


Measurement

IMA measurement has several steps:

  1. Match attributes against a policy measurement rule.

  2. If the rule applies, calculate a hash over the contents.

  3. If the hash indicates a new measurement, append the measurement to the IMA Event Log and extend the hash to a TPM PCR.

An attestation can then verify the integrity of the measurement log. A TPM attestation quote is a signature over the PCR, in effect a signature over the event log.

See Measure Policy Rule Design for implications.


Appraisal

IMA Appraisal occurs only for file data. IMA generates a hash over the file, and validates it against meta-data to determine whether the file has been tampered with. File contents (not meta-data) appraisal comes in two forms:

The Signature attribute is required if the Policy Syntax rule condition appraise_type is present. Its absence permits the Hash attribute in security.ima.

See Extended Verification Module (EVM) for file meta-data appraisal.

See Appraise Policy Rule Design for implications.

Appraisal requires files to be labeled with a security extended attribute, stored in security.ima. It can be viewed with

getfattr -m - -e hex -d <file>

where -m - requests all attributes and -d dumps the values.

Warning

https://github.com/mgerstner/ima-inspect does further parsing of the extended attributes.

FIXME Needs testing and a sample command line input and output.

Signatures have a variation, called an appended signature, where the signature is appended to the file contents rather than stored in the extended attribute.

Appraisal failures will return Permission denied. Further information can be viewed in the system audit log with

dmesg | tail

Hash

Warning

FIXME Must test all the open read write rules

This stores a file data hash in the extended attribute security.ima. The format is:

  • 0x04 - IMA_XATTR_DIGEST_NG

  • hash algorithm see Hash Algorithm

  • hash binary

See the ima_appraise boot command line argument and the appraise_type policy rule condition.

When a policy rule is triggered:

  • When in fix mode, hashes are updated on a read.

  • When in enforce mode, the hash is checked on a read and updated on a write, for both new and existing files.

    In detail, the hash is not updated on each write, which would affect performance. It is updated on the last close for write.

Use case:

A typical provisioning starts by booting with the Boot Command Line Arguments ima_appraise in fix mode. Set a custom policy to read/write. Reading all appraised files creates or updates the file hash in the security.ima extended attribute.

On subsequent boots, configure enforce mode and a read policy. This causes the system to validate the hash against the stored value before using a file. If the hash does not validate, then access will be denied.

If the use case permits system configuration files to be altered, use a read/write policy. The hash will be updated on a write, even in enforce mode, permitting a subsequent read.

Signature

Signed files are immutable.

Appraisal starts with digitally signing files. Ideally, this will be a distro signature. The signature is stored in the extended attribute security.ima. The private key is used to sign files, while the public key on the .ima keyring is used to verify signatures. The private key should not be available on the system, which provides additional protection against tampering.

When IMA verifies signatures it will use the Public Key Identifier, which is part of the IMA signature in security.ima, to find the verification public key. The format of the signature is described in the event log sig field, and includes the Public Key Identifier, Hash Algorithm and Signature Length. The evmctl utility can be used to sign files.

Use appraisal in ima_appraise enforce mode. fix mode cannot be used to re-sign a file because the private key should be held elsewhere.

A user with a private key can locally sign using evmctl.

A read policy rule will prevent a file from being read or executed if the signature does not verify.

appraise func=FILE_CHECK mask=^MAY_READ

Altering a signed file will invalidate the signature. To prevent alteration, use a policy rule such as this. The appraise on write prevents the signed file from being open for write. Without a write policy rule, the file can be written but the signature becomes invalid.

appraise func=FILE_CHECK

Audit

Audit includes file hashes in the audit log, which can be used to augment existing system security analytics/forensics. IMA-audit extends the IMA policy ABI with the Policy Syntax Action keyword audit.

There are no built-in audit policy rules.

Example policy to audit executable files and files open by user 1001:

audit func=BPRM_CHECK mask=MAY_EXEC
audit func=FILE_CHECK mask=MAY_READ fowner=1001

The audit log is in the /var/log/audit directory. The entry will have type=INTEGRITY_RULE and the entry includes:

  • file name

  • hash algorithm and hash

  • ppid, pid, uuid, uid, gid, euid, suid, fsuid, egid, sgid, fsgid

  • the command that triggered the rule


Extended Verification Module (EVM)

EVM (Extended Verification Module) detects tampering of file meta-data. EVM HMAC is limited to off-line protection. EVM Signature can also protect against runtime tampering.

EVM Signature aims at protecting files that are not expected to change while the system is running. Examples are kernel modules, as well as ELF and other binaries.

EVM appraises file meta-data and recurses from the meta-data to the file data. Since the meta-data includes security.ima, the EVM HMAC or EVM Signature covers both the data and meta-data. First security.evm is verified, followed by security.ima.

The EVM extended attribute security.evm has two forms:

  • EVM HMAC generated locally across a set of file meta-data

  • EVM Signature generated locally (for testing only) or remotely.

The file meta-data does not include the file name. It therefore does not protect against rename attacks (e.g., renaming mv to rm).

Specifically, appraisal covers this list of meta-data - extended attributes and some inode meta-data. The list is the same for EVM HMAC or EVM Signature, but a portable signature excludes the last two items, which are installation specific.

  • security.ima

  • security.selinux

  • security.SMACK64

  • security.SMACK64EXEC

  • security.SMACK64TRANSMUTE

  • security.SMACK64MMAP

  • security.apparmor

  • security.capability The capabilities associated with a superuser process.

  • uid, gid

  • mode (protections)

  • inode number (i_ino)

  • generation (i_generation)

security.selinux is included when SELinux is enabled.

security.SMACK64 is included when SMACK is enabled. The other SMACK attributes are added when CONFIG_EVM_EXTRA_SMACK_XATTRS is set.

security.apparmor is included when AppArmor is enabled.

Additional security extended attributes can be included at runtime by adding them to /sys/kernel/security/integrity/evm/evm_xattrs if CONFIG_EVM_ADD_XATTRS is set.

Warning

Needs a good example of an additional attribute.

The same IMA Appraisal rules trigger EVM appraisal if EVM is enabled. See EVM Build Flags.

Enabling EVM

The EVM extended attribute in security.evm can be viewed with

getfattr -m - -e hex -d <file>

Warning

Test this:

https://github.com/mgerstner/ima-inspect does further human readable printing of the extended attribute.

The pseudo-file /sys/kernel/security/integrity/evm/evm holds the EVM status. The default is zero / off. The file is a bitmap with the meaning:

Bit

Effect

0

Enable signature verification, HMAC verification and creation

1

Enable signature verification

2

Permit modification of EVM-protected meta-data at runtime.

Not allowed if HMAC verification and creation is enabled.

31

Disable further runtime modification of EVM state (/sys/kernel/security/integrity/evm/evm)

Before enabling EVM HMAC, the EVM HMAC key must be in /etc/keys/evm-key. The value can be set using a script enabled in the dracut module modules.d/(nn)integrity/module-setup.sh. Before enabling EVM Signature, the EVM public key certificate must be added to the .evm keyring.

There are no compile time or boot command line specifiers and no equivalent to the IMA Boot Time Custom Policy. There is an equivalent to the IMA Runtime Custom Policy, writing a value to /sys/kernel/security/integrity/evm/evm. For example:

echo 1 > /sys/kernel/security/integrity/evm/evm

will enable signature verification, HMAC verification and creation.

echo 0x80000002 > /sys/kernel/security/integrity/evm/evm

will enable signature verification and disable all further run-time modification of /sys/kernel/security/integrity/evm/evm.

The lock, bit 31 (0x80000000), is useful when bit 1 (Signature only) is set to block setting bit 0 (HMAC and signature). This limits EVM to verifying file signatures, without loading an HMAC key.

Echoing a value is additive; the new value is added to the existing initialization flags. A bit cannot be cleared. For example, after

echo 2 > /sys/kernel/security/integrity/evm/evm
echo 1 > /sys/kernel/security/integrity/evm/evm

the resulting value will be 3.

Note: While cat will show the value, the lock, bit 31, is not displayed.

EVM HMAC

This is an HMAC-sha1 across a set of security extended attributes, storing the HMAC as the extended attribute security.evm. The HMAC format is:

  • 0x02 - EVM_XATTR_HMAC

  • 20-byte HMAC-sha1 binary (fixed at SHA-1)

These steps generate an HMAC key. See https://www.kernel.org/doc/html/latest/security/keys/trusted-encrypted.html for instructions.

  1. Generate a symmetric key, called the master key, which is a trusted key type.

  2. Wrap (encrypt) the master key with the TPM storage primary key.

  3. Store the wrapped master key in the filesystem.

  4. Generate an HMAC key.

  5. Encrypt the HMAC key with the master key to create the encrypted key

  6. Store the encrypted key in the filesystem.

If CONFIG_USER_DECRYPTED_DATA is not set, the HMAC key is generated from a random number.

If CONFIG_USER_DECRYPTED_DATA is set, the HMAC key can be generated from a random number or a user provided value.

At boot:

  1. Unseal (decrypt) the master key using the TPM. The unseal typically does not currently use TPM authorization (password or PCR values).

  2. Decrypt the HMAC key from the encrypted key using the master key.

The HMAC key may be the same on multiple systems, which permits an image to be signed once. This HMAC key would be a user provided value. However, this requires this HMAC key to be present on multiple systems for verification.

  • When in fix mode, the HMAC is updated on a read.

  • When in enforce mode, the HMAC is checked on a read and updated on a write.

EVM Signature

When EVM asymmetric signature enforcement has been enabled, the verification key (X.509 certificate) must be available on the .evm keyring.

The signature format is:

  • 0x03 (EVM_IMA_XATTR_DIGSIG)

  • signature byte stream

A signature that includes the file inode and generation numbers is not portable because they will differ on each platform. A portable signature excludes them, permitting the file to be installed on multiple platforms. The main use is to include the file data and meta-data signature in a distro package.


Keyrings

The below kernel keyrings affect IMA.

Adding keys to a keyring can be measured. See CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS, func=KEY_CHECK, and the keyrings condition.

Use View a keyring to view the values

.builtin_trusted_keys

These keys (certificates) are compiled into the kernel and loaded at boot time.

View using View a keyring.

.builtin_trusted_keys verify loading of:

.machine

and

.platform

The .machine and .platform keyrings hold Machine Owner Keys (MOK). They provide separate, distinct keyrings for platform trusted keys, which the kernel automatically populates during initialization from values provided by the platform.

Additional MOK keys are registered using mokutil. At boot time, a one-time firmware (e.g. UEFI) menu prompts to accept the registered keys. See Kernel Signing Key Generation for a sample procedure.

The .machine keyring has the ability to store only CA certificates and put the rest on the .platform keyring, separating the code signing keys from the keys that are used to sign certificates. This unlocks the use of the .machine keyring as a trust anchor for IMA.

If secure boot in the UEFI firmware is disabled (see Secure Boot State), keys are not loaded onto either the .machine or .platform keyring.

if CONFIG_INTEGRITY_PLATFORM_KEYRING is clear, keys are not loaded onto either the .machine or .platform keyring.

Otherwise,if the UEFI variables MokListRT/ MokListXRT are clear, registered keys are loaded on the .platform keyring.

Otherwise, if CONFIG_INTEGRITY_CA_MACHINE_KEYRING_MAX is set, only registered CA signing key certificates (X.509 CA bit and keyCertSign true, and digitalSignature false) are loaded on the .machine keyring. The rest are loaded on the .platform keyring.

Otherwise, if CONFIG_INTEGRITY_CA_MACHINE_KEYRING is set, only the registered signing key certificates (X.509 CA bit and keyCertSign true) are loaded on the .machine keyring. The remainder are loaded on the .platform keyring.

Otherwise, if CONFIG_INTEGRITY_MACHINE_KEYRING is set, all the registered MOK keys are loaded on the .machine keyring.

Otherwise, the keys are loaded on the .platform keyring.

The .machine keyring can only be enabled if CONFIG_SECONDARY_TRUSTED_KEYRING and CONFIG_INTEGRITY_MACHINE_KEYRING are set.

These keys are loaded on the .machine or .platform keyring:

  • UEFI - Secure Boot db keys, excluding dbx keys

  • Machine owner (MOK) keys if secure boot is enabled

  • PowerPC - platform and deny listed keys for POWER

  • S390 - IPL keys

.machine keys verify loading of

.platform keys verify loading of

  • kernel modules (for some downstream distros)

  • kexec’d kernel images

.secondary_trusted_keys

These keys (certificates) are signed by a key on the .builtin_trusted_keys, .machine, or .secondary_trusted_keys keyring.

They are loaded using keyctl.

View using View a keyring.

.secondary_trusted_keys verify loading of:

.ima

Only certificates signed by a key on the .builtin_trusted_keys or .secondary_trusted_keys keyrings may be loaded onto the .ima keyring.

.ima keys are loaded from /etc/keys/ima at boot time using a dracut script modules.d/(nn)integrity/ima-keys-load.sh calling keyctl. They cannot be compiled into the kernel. If the script is absent, keys will not automatically be loaded.

Keys on the .ima keyring are used for

The key used for verification is based on the Public Key Identifier.

.evm

Only certificates signed by a key on the .builtin_trusted_keys or .secondary_trusted_keys keyrings may be loaded onto the .evm keyring.

.evm keys are loaded from /etc/keys/x509_evm.der at boot time using a dracut script calling evmctl. They cannot be compiled in. Additional keys can be loaded at runtime using evmctl.

Keys on the .evm keyring are used for

The key used for verification is based on the Public Key Identifier.

.blacklist

The .blacklist keyring holds keys and hashes that are not approved / have been revoked.

This keyring is initially populated from a revocation list. A key on .blacklist cannot be added to another keyring and cannot be used to verify another key or file EVM Signature.

The revocation keys comes from:

  • UEFI - DBX

  • Power - platform and deny listed keys for POWER

  • S390 - IPL keys

.blacklist also contain a file data Hash that is not approved.

See CONFIG_SYSTEM_BLACKLIST_KEYRING and appraise_flag.


kexec Implications

kexec Background

kexec is a soft boot. The command boots a new kernel image with new command line arguments. It does not cycle back to the hardware initialization typically performed by platform firmware.

The policy rules are set by the new kernel Build Flags and Boot Command Line Arguments.

kexec IMA Impact

Since the hardware is not initialized, the TPM PCRs, and specifically the IMA PCR, are not reset back to zeros. Therefore, an attestation will include the PCR extends from the previous kernel boot as well as the new kernel boot. In order for the verifier to validate the IMA PCR against the IMA event log, it must be presented with both the previous and current event logs. The previous event log must be carried across the kexec boot.

CONFIG_IMA_KEXEC enables the event log to be retained across a kexec. If the event log is not retained, PCR 10 cannot provide event log integrity.

Note: Even if the event log is retained, the image load copies the event log, but the new image is not executed atomically with the load. All measurements that may occur between the kexec load and execute are lost, and therefore the measurement log may not match PCR 10. Validation of the two may fail once the new kernel is running.

If no measurement log appends occur after the kexec load, validation will succeed.

Carrying the previous event log through a kexec reboot will increase the size of the in-memory log. See Measure Policy Rule Design.

kexec IMA Configuration

These items affect kexec measure and appraisal:

To support kexec verification, the IMA Template Data Fields should include buf, which records the kexec command line arguments.

This kernel configuration flag enables carrying the IMA event log across a soft boot (kexec). Since the TPM IMA PCR does not get reset upon kexec, the verifier requires both the pre- and post-kexec event logs.

This policy rule measures or appraises the kexec kernel image. See func=KEXEC_KERNEL_CHECK for the rule syntax.

This policy rule measures or appraises the kexec initramfs image. See func=KEXEC_INITRAMFS_CHECK for the rule syntax.

This policy rule measures the kexec boot command line. See func=KEXEC_CMDLINE for the rule syntax.


Appended Signatures

Appended signatures are an alternative to signatures in extended attributes or the pecoff header.

Appended signatures support these appraise policy rules:

Appended signatures are not supported for the func=FILE_CHECK rule.

A file can have both an appended signature and an extended attribute signature. Since the extended attribute signature signs the entire file, it must be calculated after the appended signature is added.

Use case: A distro can apply an appended signature. An enterprise can further lock down their platform by applying an extended attribute signature using their enterprise signing key.

To verify whether an appended signature file is present, tail the file. The content is binary, but the string Module signature appended~ is appended.

For a compressed kernel module, see the xz function.