blob: 9578247e17929bf4fcd6bd50b185f955031dc96d (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
|
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:
1: enable HMAC validation and creation
2: enable digital signature validation
3: enable HMAC and digital signature validation and HMAC
creation
Further writes will be blocked if HMAC support is enabled or
if bit 32 is set:
echo 0x80000002 ><securityfs>/evm
will enable digital signature validation and block
further writes to <securityfs>/evm.
Until this is done, 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.
|
