summaryrefslogtreecommitdiffstats
path: root/crypto/tgr192.c
diff options
context:
space:
mode:
authorMatthew Garrett <mjg59@google.com>2017-11-07 07:18:35 -0800
committerMimi Zohar <zohar@linux.vnet.ibm.com>2017-12-11 14:27:31 -0500
commitae1ba1676b88e6c62368a433c7e2d0417e9879fd (patch)
treebcbb1a5cba2e439031db519e846f89a91a8b8b2d /crypto/tgr192.c
parentb7e27bc1d42e8e0cc58b602b529c25cd0071b336 (diff)
downloadlinux-stable-ae1ba1676b88e6c62368a433c7e2d0417e9879fd.tar.gz
linux-stable-ae1ba1676b88e6c62368a433c7e2d0417e9879fd.tar.bz2
linux-stable-ae1ba1676b88e6c62368a433c7e2d0417e9879fd.zip
EVM: Allow userland to permit modification of EVM-protected metadata
When EVM is enabled it forbids modification of metadata protected by EVM unless there is already a valid EVM signature. If any modification is made, the kernel will then generate a new EVM HMAC. However, this does not map well on use cases which use only asymmetric EVM signatures, as in this scenario the kernel is unable to generate new signatures. This patch extends the /sys/kernel/security/evm interface to allow userland to request that modification of these xattrs be permitted. This is only permitted if no keys have already been loaded. In this configuration, modifying the metadata will invalidate the EVM appraisal on the file in question. This allows packaging systems to write out new files, set the relevant extended attributes and then move them into place. There's also some refactoring of the use of evm_initialized in order to avoid heading down codepaths that assume there's a key available. Signed-off-by: Matthew Garrett <mjg59@google.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Diffstat (limited to 'crypto/tgr192.c')
0 files changed, 0 insertions, 0 deletions