On Tue, 2020-05-12 at 07:54 +0000, Roberto Sassu wrote:
> > > > Roberto, EVM is only triggered by IMA, unless you've modified the
> > > > kernel to do otherwise.
> > >
> > > EVM would deny xattr/attr operations even if IMA is disabled in the
> > > kernel configuration. For example, evm_setxattr() returns the value
> > > from evm_protect_xattr(). IMA is not involved there.
> >
> > Commit ae1ba1676b88 ("EVM: Allow userland to permit modification of
> > EVM-protected metadata") introduced EVM_ALLOW_METADATA_WRITES
> > to allow writing the EVM portable and immutable file signatures.
>
> According to Documentation/ABI/testing/evm:
>
> Note that once a key has been loaded, it will no longer be
> possible to enable metadata modification.
Not any key, but the HMAC key.
2 Permit modification of EVM-protected metadata at
runtime. Not supported if HMAC validation and
creation is enabled.
Each time the EVM protected file metadata is updated, the EVM HMAC is
updated, assuming the existing EVM HMAC is valid. Userspace should
not have access to the HMAC key, so we only allow writing EVM
signatures.
The only difference between writing the original EVM signature and the
new portable and immutable signature is the security.ima xattr
requirement. Since the new EVM signature does not include the
filesystem specific data, something else needs to bind the file
metadata to the file data. Thus the IMA xattr requirement.
Assuming that the new EVM signature is written last, as long as there
is an IMA xattr, there shouldn't be a problem writing the new EVM
signature.
Mimi
