| What: security/evm |
| Date: March 2011 |
| Contact: Mimi Zohar <zohar@us.ibm.com> |
| Description: |
| EVM protects a file's security extended attributes(xattrs) |
| against integrity attacks. The initial method maintains an |
| HMAC-sha1 value across the extended attributes, storing the |
| value as the extended attribute 'security.evm'. |
| |
| EVM supports two classes of security.evm. The first is |
| an HMAC-sha1 generated locally with a |
| trusted/encrypted key stored in the Kernel Key |
| Retention System. The second is a digital signature |
| generated either locally or remotely using an |
| asymmetric key. These keys are loaded onto root's |
| keyring using keyctl, and EVM is then enabled by |
| echoing a value to <securityfs>/evm made up of the |
| following bits: |
| |
| === ================================================== |
| Bit Effect |
| === ================================================== |
| 0 Enable HMAC validation and creation |
| 1 Enable digital signature validation |
| 2 Permit modification of EVM-protected metadata at |
| runtime. Not supported if HMAC validation and |
| creation is enabled. |
| 31 Disable further runtime modification of EVM policy |
| === ================================================== |
| |
| For example:: |
| |
| echo 1 ><securityfs>/evm |
| |
| will enable HMAC validation and creation |
| |
| :: |
| |
| echo 0x80000003 ><securityfs>/evm |
| |
| will enable HMAC and digital signature validation and |
| HMAC creation and disable all further modification of policy. |
| |
| :: |
| |
| echo 0x80000006 ><securityfs>/evm |
| |
| will enable digital signature validation, permit |
| modification of EVM-protected metadata and |
| disable all further modification of policy |
| |
| Echoing a value is additive, the new value is added to the |
| existing initialization flags. |
| |
| For example, after:: |
| |
| echo 2 ><securityfs>/evm |
| |
| another echo can be performed:: |
| |
| echo 1 ><securityfs>/evm |
| |
| and the resulting value will be 3. |
| |
| Note that once an HMAC key has been loaded, it will no longer |
| be possible to enable metadata modification. Signaling that an |
| HMAC key has been loaded will clear the corresponding flag. |
| For example, if the current value is 6 (2 and 4 set):: |
| |
| echo 1 ><securityfs>/evm |
| |
| will set the new value to 3 (4 cleared). |
| |
| Loading an HMAC key is the only way to disable metadata |
| modification. |
| |
| Until key loading has been signaled EVM can not create |
| or validate the 'security.evm' xattr, but returns |
| INTEGRITY_UNKNOWN. Loading keys and signaling EVM |
| should be done as early as possible. Normally this is |
| done in the initramfs, which has already been measured |
| as part of the trusted boot. For more information on |
| creating and loading existing trusted/encrypted keys, |
| refer to: |
| Documentation/security/keys/trusted-encrypted.rst. Both |
| dracut (via 97masterkey and 98integrity) and systemd (via |
| core/ima-setup) have support for loading keys at boot |
| time. |
| |
| What: security/integrity/evm/evm_xattrs |
| Date: April 2018 |
| Contact: Matthew Garrett <mjg59@google.com> |
| Description: |
| Shows the set of extended attributes used to calculate or |
| validate the EVM signature, and allows additional attributes |
| to be added at runtime. Any signatures generated after |
| additional attributes are added (and on files possessing those |
| additional attributes) will only be valid if the same |
| additional attributes are configured on system boot. Writing |
| a single period (.) will lock the xattr list from any further |
| modification. |