73 lines
2.6 KiB
Plaintext
73 lines
2.6 KiB
Plaintext
|
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
|
||
|
|
|
||
|
|
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 <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 posessing 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.
|