123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108 |
- What: /sys/kernel/security/evm
- What: /sys/kernel/security/*/evm
- Date: March 2011
- Contact: Mimi Zohar <[email protected]>
- 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 (deprecated).
- 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. This option is now
- deprecated in favor of::
- echo 0x80000002 ><securityfs>/evm
- as the outstanding issues that prevent the usage of EVM portable
- signatures have been solved.
- 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: /sys/kernel/security/*/evm/evm_xattrs
- Date: April 2018
- Contact: Matthew Garrett <[email protected]>
- 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.
|