aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/ABI/testing/evm
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/ABI/testing/evm')
-rw-r--r--Documentation/ABI/testing/evm64
1 files changed, 50 insertions, 14 deletions
diff --git a/Documentation/ABI/testing/evm b/Documentation/ABI/testing/evm
index 8374d4557e5d..d12cb2eae9ee 100644
--- a/Documentation/ABI/testing/evm
+++ b/Documentation/ABI/testing/evm
@@ -7,17 +7,53 @@ Description:
HMAC-sha1 value across the extended attributes, storing the
value as the extended attribute 'security.evm'.
- EVM depends on the Kernel Key Retention System to provide it
- with a trusted/encrypted key for the HMAC-sha1 operation.
- The key is loaded onto the root's keyring using keyctl. Until
- EVM receives notification that the key has been successfully
- loaded onto the keyring (echo 1 > <securityfs>/evm), EVM
- can not create or validate the 'security.evm' xattr, but
- returns INTEGRITY_UNKNOWN. Loading the key 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/keys-trusted-encrypted.txt. (A sample dracut
- patch, which loads the trusted/encrypted key and enables
- EVM, is available from http://linux-ima.sourceforge.net/#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
+
+ Note that once a key has been loaded, it will no longer be
+ possible to enable 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.