forked from Qortal/Brooklyn
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
79 lines
2.8 KiB
79 lines
2.8 KiB
What: 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. |
|
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. |
|
|
|
What: security/integrity/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.
|
|
|