EVM portable signatures are particularly suitable for the protection of
metadata of immutable files where metadata is signed by a software vendor.
They can be used for example in conjunction with an IMA policy that
appraises only executed and memory mapped files.
However, until now portable signatures can be properly installed only if
the EVM_ALLOW_METADATA_WRITES initialization flag is also set, which
disables metadata verification until an HMAC key is loaded. This will cause
metadata writes to be allowed even in the situations where they shouldn't
(metadata protected by a portable signature is immutable).
The main reason why setting the flag is necessary is that the operations
necessary to install portable signatures and protected metadata would be
otherwise denied, despite being legitimate, due to the fact that the
decision logic has to avoid an unsafe recalculation of the HMAC that would
make the unsuccessfully verified metadata valid. However, the decision
logic is too coarse, and does not fully take into account all the possible
situations where metadata operations could be allowed.
For example, if the HMAC key is not loaded and it cannot be loaded in the
future due the EVM_SETUP_COMPLETE flag being set, it wouldn't be a problem
to allow metadata operations, as they wouldn't result in an HMAC being
recalculated.
This patch set extends the decision logic and adds the necessary exceptions
to use portable signatures without turning off metadata verification and
deprecates the EVM_ALLOW_METADATA_WRITES flag.
More in detail, patch 1 allows EVM to be used without loading an HMAC key.
Patch 2 avoids appraisal verification of public keys (they are already
verified by the key subsystem).
Patches 3-4 still allow to turn off metadata verification but in a safe way
(by ensuring that IMA revalidates metadata when there is a change).
Patches 5-8 extend the decision logic to keep the metadata verification on,
by ignoring the INTEGRITY_NOLABEL and INTEGRITY_NOXATTS errors when
possible, by accepting any metadata modification until signature
verification succeeds (useful when xattrs/attrs are copied sequentially
from a source) and afterwards by only allowing operations that don't change
metadata.
Patch 9 deprecates the EVM_ALLOW_METADATA_WRITES flag after the decision
logic has been extended with the above exceptions.
Patch 10 makes it possible to use portable signatures when the IMA policy
requires file signatures and patch 11 shows portable signatures in the
measurement list when the ima-sig template is selected.
Lastly, patch 12 avoids undesired removal of security.ima when a file is
not selected by the IMA policy.
Test:
https://github.com/robertosassu/ima-evm-utils/blob/ima-evm-fixes-v7-devel-v3/tests/portable_signatures.test
Test results:
https://travis-ci.com/github/robertosassu/ima-evm-utils/jobs/505367559https://travis-ci.com/github/robertosassu/ima-evm-utils/jobs/505367563
Changelog
v6:
- update documentation to deprecate EVM_ALLOW_METADATA_WRITES and to
clarify how <securityfs>/evm should be used (suggested by Mimi)
- rename evm_status_revalidate() to evm_revalidate_status() (suggested by
Mimi)
- revalidate status also when security.evm is modified (suggested by Mimi)
v5:
- remove IMA xattr post hooks and call evm_revalidate() from pre hooks
(suggested by Mimi)
- rename evm_ignore_error_safe() to evm_hmac_disabled() and check the errors
inline (suggested by Mimi)
- improve readability of error handling in evm_verify_hmac() (suggested by Mimi)
- don't show an error message if the EVM status is INTEGRITY_PASS_IMMUTABLE
(suggested by Mimi)
- check if CONFIG_FS_POSIX_ACL is defined in evm_xattr_acl_change() (reported
by kernel test robot)
- fix return value of evm_xattr_change() (suggested by Christian Brauner)
- simplify EVM_ALLOW_METADATA_WRITES check in evm_write_key() (suggested by
Mimi)
v4:
- add patch to pass mnt_userns to EVM inode set/remove xattr hooks
(suggested by Christian Brauner)
- pass mnt_userns to posix_acl_update_mode()
- use IS_ERR_OR_NULL() in evm_xattr_acl_change() (suggested by Mimi)
v3:
- introduce evm_ignore_error_safe() to correctly ignore INTEGRITY_NOLABEL
and INTEGRITY_NOXATTRS errors
- fix an error in evm_xattr_acl_change()
- replace #ifndef with !IS_ENABLED() in integrity_load_keys()
- reintroduce ima_inode_removexattr()
- adapt patches to apply on top of the idmapped mounts patch set
v2:
- replace EVM_RESET_STATUS flag with evm_status_revalidate()
- introduce IMA post hooks ima_inode_post_setxattr() and
ima_inode_post_removexattr()
- remove ima_inode_removexattr()
- ignore INTEGRITY_NOLABEL error if the HMAC key is not loaded
v1:
- introduce EVM_RESET_STATUS integrity flag instead of clearing IMA flag
- introduce new template field evmsig
- add description of evm_xattr_acl_change() and evm_xattr_change()
Roberto Sassu (12):
evm: Execute evm_inode_init_security() only when an HMAC key is loaded
evm: Load EVM key in ima_load_x509() to avoid appraisal
evm: Refuse EVM_ALLOW_METADATA_WRITES only if an HMAC key is loaded
evm: Introduce evm_revalidate_status()
evm: Introduce evm_hmac_disabled() to safely ignore verification
errors
evm: Allow xattr/attr operations for portable signatures
evm: Pass user namespace to set/remove xattr hooks
evm: Allow setxattr() and setattr() for unmodified metadata
evm: Deprecate EVM_ALLOW_METADATA_WRITES
ima: Allow imasig requirement to be satisfied by EVM portable
signatures
ima: Introduce template field evmsig and write to field sig as
fallback
ima: Don't remove security.ima if file must not be appraised
Documentation/ABI/testing/evm | 36 +++-
Documentation/security/IMA-templates.rst | 4 +-
include/linux/evm.h | 18 +-
include/linux/integrity.h | 1 +
security/integrity/evm/evm_main.c | 245 ++++++++++++++++++++--
security/integrity/evm/evm_secfs.c | 8 +-
security/integrity/iint.c | 4 +-
security/integrity/ima/ima_appraise.c | 43 ++--
security/integrity/ima/ima_init.c | 4 +
security/integrity/ima/ima_template.c | 2 +
security/integrity/ima/ima_template_lib.c | 33 ++-
security/integrity/ima/ima_template_lib.h | 2 +
security/security.c | 4 +-
13 files changed, 353 insertions(+), 51 deletions(-)
--
2.25.1
The public builtin keys do not need to be appraised by IMA as the
restriction on the IMA/EVM trusted keyrings ensures that a key can be
loaded only if it is signed with a key on the builtin or secondary
keyrings.
However, when evm_load_x509() is called, appraisal is already enabled and
a valid IMA signature must be added to the EVM key to pass verification.
Since the restriction is applied on both IMA and EVM trusted keyrings, it
is safe to disable appraisal also when the EVM key is loaded. This patch
calls evm_load_x509() inside ima_load_x509() if CONFIG_IMA_LOAD_X509 is
enabled, which crosses the normal IMA and EVM boundary.
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
---
security/integrity/iint.c | 4 +++-
security/integrity/ima/ima_init.c | 4 ++++
2 files changed, 7 insertions(+), 1 deletion(-)
evm_inode_init_security() requires an HMAC key to calculate the HMAC on
initial xattrs provided by LSMs. However, it checks generically whether a
key has been loaded, including also public keys, which is not correct as
public keys are not suitable to calculate the HMAC.
Originally, support for signature verification was introduced to verify a
possibly immutable initial ram disk, when no new files are created, and to
switch to HMAC for the root filesystem. By that time, an HMAC key should
have been loaded and usable to calculate HMACs for new files.
More recently support for requiring an HMAC key was removed from the
kernel, so that signature verification can be used alone. Since this is a
legitimate use case, evm_inode_init_security() should not return an error
when no HMAC key has been loaded.
This patch fixes this problem by replacing the evm_key_loaded() check with
a check of the EVM_INIT_HMAC flag in evm_initialized.
Cc: stable@vger.kernel.org # 4.5.x
Fixes: 26ddabfe96b ("evm: enable EVM when X509 certificate is loaded")
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
---
security/integrity/evm/evm_main.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
EVM_ALLOW_METADATA_WRITES is an EVM initialization flag that can be set to
temporarily disable metadata verification until all xattrs/attrs necessary
to verify an EVM portable signature are copied to the file. This flag is
cleared when EVM is initialized with an HMAC key, to avoid that the HMAC is
calculated on unverified xattrs/attrs.
Currently EVM unnecessarily denies setting this flag if EVM is initialized
with a public key, which is not a concern as it cannot be used to trust
xattrs/attrs updates. This patch removes this limitation.
Cc: stable@vger.kernel.org # 4.16.x
Fixes: ae1ba1676b88e ("EVM: Allow userland to permit modification of EVM-protected metadata")
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
---
Documentation/ABI/testing/evm | 26 ++++++++++++++++++++++++--
security/integrity/evm/evm_secfs.c | 8 ++++----
2 files changed, 28 insertions(+), 6 deletions(-)
@@ -49,8 +49,30 @@ Description: 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.+ 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
When EVM_ALLOW_METADATA_WRITES is set, EVM allows any operation on
metadata. Its main purpose is to allow users to freely set metadata when it
is protected by a portable signature, until an HMAC key is loaded.
However, callers of evm_verifyxattr() are not notified about metadata
changes and continue to rely on the last status returned by the function.
For example IMA, since it caches the appraisal result, will not call again
evm_verifyxattr() until the appraisal flags are cleared, and will grant
access to the file even if there was a metadata operation that made the
portable signature invalid.
This patch introduces evm_revalidate_status(), which callers of
evm_verifyxattr() can use in their xattr hooks to determine whether
re-validation is necessary and to do the proper actions. IMA calls it in
its xattr hooks to reset the appraisal flags, so that the EVM status is
re-evaluated after a metadata operation.
Lastly, this patch also adds a call to evm_reset_status() in
evm_inode_post_setattr() to invalidate the cached EVM status after a
setattr operation.
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
---
include/linux/evm.h | 6 ++++
security/integrity/evm/evm_main.c | 40 ++++++++++++++++++++++++---
security/integrity/ima/ima_appraise.c | 15 ++++++----
3 files changed, 52 insertions(+), 9 deletions(-)
When a file is being created, LSMs can set the initial label with the
inode_init_security hook. If no HMAC key is loaded, the new file will have
LSM xattrs but not the HMAC. It is also possible that the file remains
without protected xattrs after creation if no active LSM provided it.
Unfortunately, EVM will deny any further metadata operation on new files,
as evm_protect_xattr() will always return the INTEGRITY_NOLABEL error, or
INTEGRITY_NOXATTRS if no protected xattrs exist. This would limit the
usability of EVM when only a public key is loaded, as commands such as cp
or tar with the option to preserve xattrs won't work.
This patch introduces the evm_hmac_disabled() function to determine whether
or not it is safe to ignore verification errors, based on the ability of
EVM to calculate HMACs. If the HMAC key is not loaded, and it cannot be
loaded in the future due to the EVM_SETUP_COMPLETE initialization flag,
allowing an operation despite the attrs/xattrs being found invalid will not
make them valid.
Since the post hooks can be executed even when the HMAC key is not loaded,
this patch also ensures that the EVM_INIT_HMAC initialization flag is set
before the post hooks call evm_update_evmxattr().
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
---
security/integrity/evm/evm_main.c | 37 ++++++++++++++++++++++++++++++-
1 file changed, 36 insertions(+), 1 deletion(-)
@@ -338,6 +356,10 @@ static int evm_protect_xattr(struct dentry *dentry, const char *xattr_name,if(evm_status==INTEGRITY_NOXATTRS){structintegrity_iint_cache*iint;+/* Exception if the HMAC is not going to be calculated. */+if(evm_hmac_disabled())+return0;+iint=integrity_iint_find(d_backing_inode(dentry));if(iint&&(iint->flags&IMA_NEW_FILE))return0;
@@ -354,6 +376,9 @@ static int evm_protect_xattr(struct dentry *dentry, const char *xattr_name,-EPERM,0);}out:+/* Exception if the HMAC is not going to be calculated. */+if(evm_hmac_disabled()&&evm_status==INTEGRITY_NOLABEL)+return0;if(evm_status!=INTEGRITY_PASS)integrity_audit_msg(AUDIT_INTEGRITY_METADATA,d_backing_inode(dentry),dentry->d_name.name,"appraise_metadata",
If files with portable signatures are copied from one location to another
or are extracted from an archive, verification can temporarily fail until
all xattrs/attrs are set in the destination. Only portable signatures may
be moved or copied from one file to another, as they don't depend on
system-specific information such as the inode generation. Instead portable
signatures must include security.ima.
Unlike other security.evm types, EVM portable signatures are also
immutable. Thus, it wouldn't be a problem to allow xattr/attr operations
when verification fails, as portable signatures will never be replaced with
the HMAC on possibly corrupted xattrs/attrs.
This patch first introduces a new integrity status called
INTEGRITY_FAIL_IMMUTABLE, that allows callers of
evm_verify_current_integrity() to detect that a portable signature didn't
pass verification and then adds an exception in evm_protect_xattr() and
evm_inode_setattr() for this status and returns 0 instead of -EPERM.
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
---
include/linux/integrity.h | 1 +
security/integrity/evm/evm_main.c | 33 ++++++++++++++++++++++-----
security/integrity/ima/ima_appraise.c | 2 ++
3 files changed, 30 insertions(+), 6 deletions(-)
@@ -379,6 +387,14 @@ static int evm_protect_xattr(struct dentry *dentry, const char *xattr_name,/* Exception if the HMAC is not going to be calculated. */if(evm_hmac_disabled()&&evm_status==INTEGRITY_NOLABEL)return0;++/*+*Writingotherxattrsissafeforportablesignatures,asportable+*signaturesareimmutableandcanneverbeupdated.+*/+if(evm_status==INTEGRITY_FAIL_IMMUTABLE)+return0;+if(evm_status!=INTEGRITY_PASS)integrity_audit_msg(AUDIT_INTEGRITY_METADATA,d_backing_inode(dentry),dentry->d_name.name,"appraise_metadata",
In preparation for 'evm: Allow setxattr() and setattr() for unmodified
metadata', this patch passes mnt_userns to the inode set/remove xattr hooks
so that the GID of the inode on an idmapped mount is correctly determined
by posix_acl_update_mode().
Cc: Christian Brauner <redacted>
Cc: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Reviewed-by: Christian Brauner <redacted>
---
include/linux/evm.h | 12 ++++++++----
security/integrity/evm/evm_main.c | 17 +++++++++++------
security/security.c | 4 ++--
3 files changed, 21 insertions(+), 12 deletions(-)
@@ -434,19 +437,21 @@ int evm_inode_setxattr(struct dentry *dentry, const char *xattr_name,xattr_data->type!=EVM_XATTR_PORTABLE_DIGSIG)return-EPERM;}-returnevm_protect_xattr(dentry,xattr_name,xattr_value,+returnevm_protect_xattr(mnt_userns,dentry,xattr_name,xattr_value,xattr_value_len);}/***evm_inode_removexattr-protecttheEVMextendedattribute+*@mnt_userns:usernamespaceoftheidmappedmount*@dentry:pointertotheaffecteddentry*@xattr_name:pointertotheaffectedextendedattributename**Removing'security.evm'requiresCAP_SYS_ADMINprivilegesandthat*thecurrentvalueisvalid.*/-intevm_inode_removexattr(structdentry*dentry,constchar*xattr_name)+intevm_inode_removexattr(structuser_namespace*mnt_userns,+structdentry*dentry,constchar*xattr_name){/* Policy permits modification of the protected xattrs even though*there'snoHMACkeyloaded
With the patch to allow xattr/attr operations if a portable signature
verification fails, cp and tar can copy all xattrs/attrs so that at the
end of the process verification succeeds.
However, it might happen that the xattrs/attrs are already set to the
correct value (taken at signing time) and signature verification succeeds
before the copy has completed. For example, an archive might contains files
owned by root and the archive is extracted by root.
Then, since portable signatures are immutable, all subsequent operations
fail (e.g. fchown()), even if the operation is legitimate (does not alter
the current value).
This patch avoids this problem by reporting successful operation to user
space when that operation does not alter the current value of xattrs/attrs.
With this patch, the one that introduces evm_hmac_disabled() and the one
that allows a metadata operation on the INTEGRITY_FAIL_IMMUTABLE error, EVM
portable signatures can be used without disabling metadata verification
(by setting EVM_ALLOW_METADATA_WRITES). Due to keeping metadata
verification enabled, altering immutable metadata protected with a portable
signature that was successfully verified will be denied (existing
behavior).
Cc: Christian Brauner <redacted>
Cc: Andreas Gruenbacher <agruenba@redhat.com>
Reported-by: kernel test robot <redacted>
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Reviewed-by: Christian Brauner <redacted>
---
security/integrity/evm/evm_main.c | 113 +++++++++++++++++++++++++++++-
1 file changed, 112 insertions(+), 1 deletion(-)
This patch deprecates the usage of EVM_ALLOW_METADATA_WRITES, as it is no
longer necessary. All the issues that prevent the usage of EVM portable
signatures just with a public key loaded have been solved.
This flag will remain available for a short time to ensure that users are
able to use EVM without it.
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
---
Documentation/ABI/testing/evm | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
@@ -24,7 +24,7 @@ Description: 1 Enable digital signature validation 2 Permit modification of EVM-protected metadata at runtime. Not supported if HMAC validation and- creation is enabled.+ creation is enabled (deprecated). 31 Disable further runtime modification of EVM policy === ==================================================
@@ -47,7 +47,13 @@ Description: will enable digital signature validation, permit modification of EVM-protected metadata and- disable all further modification of policy+ 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.
System administrators can require that all accessed files have a signature
by specifying appraise_type=imasig in a policy rule.
Currently, IMA signatures satisfy this requirement. Appended signatures may
also satisfy this requirement, but are not applicable as IMA signatures.
IMA/appended signatures ensure data source authentication for file content
and prevent any change. EVM signatures instead ensure data source
authentication for file metadata. Given that the digest or signature of the
file content must be included in the metadata, EVM signatures provide the
same file data guarantees of IMA signatures, as well as providing file
metadata guarantees.
This patch lets systems protected with EVM signatures pass appraisal
verification if the appraise_type=imasig requirement is specified in the
policy. This facilitates deployment in the scenarios where only EVM
signatures are available.
The patch makes the following changes:
file xattr types:
security.ima: IMA_XATTR_DIGEST/IMA_XATTR_DIGEST_NG
security.evm: EVM_XATTR_PORTABLE_DIGSIG
execve(), mmap(), open() behavior (with appraise_type=imasig):
before: denied (file without IMA signature, imasig requirement not met)
after: allowed (file with EVM portable signature, imasig requirement met)
open(O_WRONLY) behavior (without appraise_type=imasig):
before: allowed (file without IMA signature, not immutable)
after: denied (file with EVM portable signature, immutable)
In addition, similarly to IMA signatures, this patch temporarily allows
new files without or with incomplete metadata to be opened so that content
can be written.
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
---
security/integrity/ima/ima_appraise.c | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)
@@ -461,9 +466,12 @@ int ima_appraise_measurement(enum ima_hooks func,status=INTEGRITY_PASS;}-/* Permit new files with file signatures, but without data. */+/*+*Permitnewfileswithfile/EVMportablesignatures,but+*withoutdata.+*/if(inode->i_size==0&&iint->flags&IMA_NEW_FILE&&-xattr_value&&xattr_value->type==EVM_IMA_XATTR_DIGSIG){+test_bit(IMA_DIGSIG,&iint->atomic_flags)){status=INTEGRITY_PASS;}
With the patch to accept EVM portable signatures when the
appraise_type=imasig requirement is specified in the policy, appraisal can
be successfully done even if the file does not have an IMA signature.
However, remote attestation would not see that a different signature type
was used, as only IMA signatures can be included in the measurement list.
This patch solves the issue by introducing the new template field 'evmsig'
to show EVM portable signatures and by including its value in the existing
field 'sig' if the IMA signature is not found.
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
---
Documentation/security/IMA-templates.rst | 4 ++-
security/integrity/ima/ima_template.c | 2 ++
security/integrity/ima/ima_template_lib.c | 33 ++++++++++++++++++++++-
security/integrity/ima/ima_template_lib.h | 2 ++
4 files changed, 39 insertions(+), 2 deletions(-)
@@ -70,9 +70,11 @@ descriptors by adding their identifier to the format string prefix is shown only if the hash algorithm is not SHA1 or MD5);- 'd-modsig': the digest of the event without the appended modsig;- 'n-ng': the name of the event, without size limitations;-- 'sig': the file signature;+- 'sig': the file signature, or the EVM portable signature if the file+ signature is not found;- 'modsig' the appended file signature;- 'buf': the buffer data that was used to generate the hash without size limitations;+- 'evmsig': the EVM portable signature; Below, there is the list of defined template descriptors:
Files might come from a remote source and might have xattrs, including
security.ima. It should not be IMA task to decide whether security.ima
should be kept or not. This patch removes the removexattr() system
call in ima_inode_post_setattr().
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
---
security/integrity/ima/ima_appraise.c | 2 --
1 file changed, 2 deletions(-)
When a file is being created, LSMs can set the initial label with the
inode_init_security hook. If no HMAC key is loaded, the new file will have
LSM xattrs but not the HMAC. It is also possible that the file remains
without protected xattrs after creation if no active LSM provided it, or
because the filesystem does not support them.
Unfortunately, EVM will deny any further metadata operation on new files,
as evm_protect_xattr() will return the INTEGRITY_NOLABEL error if protected
xattrs exist without security.evm, INTEGRITY_NOXATTRS if no protected
xattrs exist or INTEGRITY_UNKNOWN if xattrs are not supported. This would
limit the usability of EVM when only a public key is loaded, as commands
such as cp or tar with the option to preserve xattrs won't work.
This patch introduces the evm_hmac_disabled() function to determine whether
or not it is safe to ignore verification errors, based on the ability of
EVM to calculate HMACs. If the HMAC key is not loaded, and it cannot be
loaded in the future due to the EVM_SETUP_COMPLETE initialization flag,
allowing an operation despite the attrs/xattrs being found invalid will not
make them valid.
Since the post hooks can be executed even when the HMAC key is not loaded,
this patch also ensures that the EVM_INIT_HMAC initialization flag is set
before the post hooks call evm_update_evmxattr().
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
---
security/integrity/evm/evm_main.c | 39 ++++++++++++++++++++++++++++++-
1 file changed, 38 insertions(+), 1 deletion(-)
@@ -338,6 +356,10 @@ static int evm_protect_xattr(struct dentry *dentry, const char *xattr_name,if(evm_status==INTEGRITY_NOXATTRS){structintegrity_iint_cache*iint;+/* Exception if the HMAC is not going to be calculated. */+if(evm_hmac_disabled())+return0;+iint=integrity_iint_find(d_backing_inode(dentry));if(iint&&(iint->flags&IMA_NEW_FILE))return0;
@@ -354,6 +376,10 @@ static int evm_protect_xattr(struct dentry *dentry, const char *xattr_name,-EPERM,0);}out:+/* Exception if the HMAC is not going to be calculated. */+if(evm_hmac_disabled()&&(evm_status==INTEGRITY_NOLABEL||+evm_status==INTEGRITY_UNKNOWN))+return0;if(evm_status!=INTEGRITY_PASS)integrity_audit_msg(AUDIT_INTEGRITY_METADATA,d_backing_inode(dentry),dentry->d_name.name,"appraise_metadata",
From: Roberto Sassu
Sent: Thursday, May 20, 2021 10:49 AM
When a file is being created, LSMs can set the initial label with the
inode_init_security hook. If no HMAC key is loaded, the new file will have
LSM xattrs but not the HMAC. It is also possible that the file remains
without protected xattrs after creation if no active LSM provided it, or
because the filesystem does not support them.
Unfortunately, EVM will deny any further metadata operation on new files,
as evm_protect_xattr() will return the INTEGRITY_NOLABEL error if protected
xattrs exist without security.evm, INTEGRITY_NOXATTRS if no protected
xattrs exist or INTEGRITY_UNKNOWN if xattrs are not supported. This would
limit the usability of EVM when only a public key is loaded, as commands
such as cp or tar with the option to preserve xattrs won't work.
This patch introduces the evm_hmac_disabled() function to determine whether
or not it is safe to ignore verification errors, based on the ability of
EVM to calculate HMACs. If the HMAC key is not loaded, and it cannot be
loaded in the future due to the EVM_SETUP_COMPLETE initialization flag,
allowing an operation despite the attrs/xattrs being found invalid will not
make them valid.
Since the post hooks can be executed even when the HMAC key is not loaded,
this patch also ensures that the EVM_INIT_HMAC initialization flag is set
before the post hooks call evm_update_evmxattr().
Resending, to ignore INTEGRITY_UNKNOWN when a filesystem does not
support xattrs.
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Li Jian, Shi Yanli
the
+ * attrs/xattrs being found invalid will not make them valid.
+ */
+static bool evm_hmac_disabled(void)
+{
+ if (evm_initialized & EVM_INIT_HMAC)
+ return false;
+
+ if (!(evm_initialized & EVM_SETUP_COMPLETE))
+ return false;
+
+ return true;
+}
+
static int evm_find_protected_xattrs(struct dentry *dentry)
{
struct inode *inode = d_backing_inode(dentry);
@@ -338,6 +356,10 @@ static int evm_protect_xattr(struct dentry *dentry,
const char *xattr_name,
if (evm_status == INTEGRITY_NOXATTRS) {
struct integrity_iint_cache *iint;
+ /* Exception if the HMAC is not going to be calculated. */
+ if (evm_hmac_disabled())
+ return 0;
+
iint = integrity_iint_find(d_backing_inode(dentry));
if (iint && (iint->flags & IMA_NEW_FILE))
return 0;
@@ -354,6 +376,10 @@ static int evm_protect_xattr(struct dentry *dentry,
const char *xattr_name,
-EPERM, 0);
}
out:
+ /* Exception if the HMAC is not going to be calculated. */
+ if (evm_hmac_disabled() && (evm_status == INTEGRITY_NOLABEL ||
+ evm_status == INTEGRITY_UNKNOWN))
+ return 0;
if (evm_status != INTEGRITY_PASS)
integrity_audit_msg(AUDIT_INTEGRITY_METADATA,
d_backing_inode(dentry),
dentry->d_name.name,
"appraise_metadata",
On Fri, 2021-05-14 at 17:27 +0200, Roberto Sassu wrote:
EVM portable signatures are particularly suitable for the protection of
metadata of immutable files where metadata is signed by a software vendor.
They can be used for example in conjunction with an IMA policy that
appraises only executed and memory mapped files.
However, until now portable signatures can be properly installed only if
the EVM_ALLOW_METADATA_WRITES initialization flag is also set, which
disables metadata verification until an HMAC key is loaded. This will cause
metadata writes to be allowed even in the situations where they shouldn't
(metadata protected by a portable signature is immutable).
The main reason why setting the flag is necessary is that the operations
necessary to install portable signatures and protected metadata would be
otherwise denied, despite being legitimate, due to the fact that the
decision logic has to avoid an unsafe recalculation of the HMAC that would
make the unsuccessfully verified metadata valid. However, the decision
logic is too coarse, and does not fully take into account all the possible
situations where metadata operations could be allowed.
For example, if the HMAC key is not loaded and it cannot be loaded in the
future due the EVM_SETUP_COMPLETE flag being set, it wouldn't be a problem
to allow metadata operations, as they wouldn't result in an HMAC being
recalculated.
This patch set extends the decision logic and adds the necessary exceptions
to use portable signatures without turning off metadata verification and
deprecates the EVM_ALLOW_METADATA_WRITES flag.
Thanks, Roberto.
Applied to: git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-
integrity.git
next-integrity-testing
Mimi
From: Mimi Zohar [mailto:zohar@linux.ibm.com]
Sent: Thursday, May 20, 2021 8:56 PM
On Fri, 2021-05-14 at 17:27 +0200, Roberto Sassu wrote:
quoted
EVM portable signatures are particularly suitable for the protection of
metadata of immutable files where metadata is signed by a software vendor.
They can be used for example in conjunction with an IMA policy that
appraises only executed and memory mapped files.
However, until now portable signatures can be properly installed only if
the EVM_ALLOW_METADATA_WRITES initialization flag is also set, which
disables metadata verification until an HMAC key is loaded. This will cause
metadata writes to be allowed even in the situations where they shouldn't
(metadata protected by a portable signature is immutable).
The main reason why setting the flag is necessary is that the operations
necessary to install portable signatures and protected metadata would be
otherwise denied, despite being legitimate, due to the fact that the
decision logic has to avoid an unsafe recalculation of the HMAC that would
make the unsuccessfully verified metadata valid. However, the decision
logic is too coarse, and does not fully take into account all the possible
situations where metadata operations could be allowed.
For example, if the HMAC key is not loaded and it cannot be loaded in the
future due the EVM_SETUP_COMPLETE flag being set, it wouldn't be a
problem
quoted
to allow metadata operations, as they wouldn't result in an HMAC being
recalculated.
This patch set extends the decision logic and adds the necessary exceptions
to use portable signatures without turning off metadata verification and
deprecates the EVM_ALLOW_METADATA_WRITES flag.
Thanks, Roberto.
Applied to: git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-
integrity.git
next-integrity-testing
On Fri, 2021-05-21 at 07:07 +0000, Roberto Sassu wrote:
quoted
From: Mimi Zohar [mailto:zohar@linux.ibm.com]
Sent: Thursday, May 20, 2021 8:56 PM
On Fri, 2021-05-14 at 17:27 +0200, Roberto Sassu wrote:
quoted
EVM portable signatures are particularly suitable for the protection of
metadata of immutable files where metadata is signed by a software vendor.
They can be used for example in conjunction with an IMA policy that
appraises only executed and memory mapped files.
However, until now portable signatures can be properly installed only if
the EVM_ALLOW_METADATA_WRITES initialization flag is also set, which
disables metadata verification until an HMAC key is loaded. This will cause
metadata writes to be allowed even in the situations where they shouldn't
(metadata protected by a portable signature is immutable).
The main reason why setting the flag is necessary is that the operations
necessary to install portable signatures and protected metadata would be
otherwise denied, despite being legitimate, due to the fact that the
decision logic has to avoid an unsafe recalculation of the HMAC that would
make the unsuccessfully verified metadata valid. However, the decision
logic is too coarse, and does not fully take into account all the possible
situations where metadata operations could be allowed.
For example, if the HMAC key is not loaded and it cannot be loaded in the
future due the EVM_SETUP_COMPLETE flag being set, it wouldn't be a
problem
quoted
to allow metadata operations, as they wouldn't result in an HMAC being
recalculated.
This patch set extends the decision logic and adds the necessary exceptions
to use portable signatures without turning off metadata verification and
deprecates the EVM_ALLOW_METADATA_WRITES flag.
Thanks, Roberto.
Applied to: git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-
integrity.git
next-integrity-testing
Hi Mimi
could you please take the newer version of patch 5/12, which also adds
an exception for the INTEGRITY_UNKNOWN error (it occurs when xattrs
are not supported)?
Thank you for catching it. I'd appreciate your checking once more.
FYI, get-lore-mbox.py moved "Cc: stable" to the end.
thanks,
Mimi