0001 What: /sys/kernel/security/evm
0002 What: /sys/kernel/security/*/evm
0003 Date: March 2011
0004 Contact: Mimi Zohar <zohar@us.ibm.com>
0005 Description:
0006 EVM protects a file's security extended attributes(xattrs)
0007 against integrity attacks. The initial method maintains an
0008 HMAC-sha1 value across the extended attributes, storing the
0009 value as the extended attribute 'security.evm'.
0010
0011 EVM supports two classes of security.evm. The first is
0012 an HMAC-sha1 generated locally with a
0013 trusted/encrypted key stored in the Kernel Key
0014 Retention System. The second is a digital signature
0015 generated either locally or remotely using an
0016 asymmetric key. These keys are loaded onto root's
0017 keyring using keyctl, and EVM is then enabled by
0018 echoing a value to <securityfs>/evm made up of the
0019 following bits:
0020
0021 === ==================================================
0022 Bit Effect
0023 === ==================================================
0024 0 Enable HMAC validation and creation
0025 1 Enable digital signature validation
0026 2 Permit modification of EVM-protected metadata at
0027 runtime. Not supported if HMAC validation and
0028 creation is enabled (deprecated).
0029 31 Disable further runtime modification of EVM policy
0030 === ==================================================
0031
0032 For example::
0033
0034 echo 1 ><securityfs>/evm
0035
0036 will enable HMAC validation and creation
0037
0038 ::
0039
0040 echo 0x80000003 ><securityfs>/evm
0041
0042 will enable HMAC and digital signature validation and
0043 HMAC creation and disable all further modification of policy.
0044
0045 ::
0046
0047 echo 0x80000006 ><securityfs>/evm
0048
0049 will enable digital signature validation, permit
0050 modification of EVM-protected metadata and
0051 disable all further modification of policy. This option is now
0052 deprecated in favor of::
0053
0054 echo 0x80000002 ><securityfs>/evm
0055
0056 as the outstanding issues that prevent the usage of EVM portable
0057 signatures have been solved.
0058
0059 Echoing a value is additive, the new value is added to the
0060 existing initialization flags.
0061
0062 For example, after::
0063
0064 echo 2 ><securityfs>/evm
0065
0066 another echo can be performed::
0067
0068 echo 1 ><securityfs>/evm
0069
0070 and the resulting value will be 3.
0071
0072 Note that once an HMAC key has been loaded, it will no longer
0073 be possible to enable metadata modification. Signaling that an
0074 HMAC key has been loaded will clear the corresponding flag.
0075 For example, if the current value is 6 (2 and 4 set)::
0076
0077 echo 1 ><securityfs>/evm
0078
0079 will set the new value to 3 (4 cleared).
0080
0081 Loading an HMAC key is the only way to disable metadata
0082 modification.
0083
0084 Until key loading has been signaled EVM can not create
0085 or validate the 'security.evm' xattr, but returns
0086 INTEGRITY_UNKNOWN. Loading keys and signaling EVM
0087 should be done as early as possible. Normally this is
0088 done in the initramfs, which has already been measured
0089 as part of the trusted boot. For more information on
0090 creating and loading existing trusted/encrypted keys,
0091 refer to:
0092 Documentation/security/keys/trusted-encrypted.rst. Both
0093 dracut (via 97masterkey and 98integrity) and systemd (via
0094 core/ima-setup) have support for loading keys at boot
0095 time.
0096
0097 What: /sys/kernel/security/*/evm/evm_xattrs
0098 Date: April 2018
0099 Contact: Matthew Garrett <mjg59@google.com>
0100 Description:
0101 Shows the set of extended attributes used to calculate or
0102 validate the EVM signature, and allows additional attributes
0103 to be added at runtime. Any signatures generated after
0104 additional attributes are added (and on files possessing those
0105 additional attributes) will only be valid if the same
0106 additional attributes are configured on system boot. Writing
0107 a single period (.) will lock the xattr list from any further
0108 modification.
