On Tue, 2017-10-17 at 16:12 -0700, Matthew Garrett wrote: > I'm interested in extending our use of IMA digital signatures to EVM > in order to protect security.capability (and, in the near future, > security.apparmor). security.capability is already included in the EVM HMAC/signature. Your security.apparmor patch is now queued in my #next branch. > However, right now this doesn't seem to quite work > in terms of allowing updates to a running system. ? > We've discussed the > EVM siganture format's use of inode numbers and I think I've got that > sorted (I'll send a patch once I've got a last couple of things > working). Ok > > However, I'm a little confused by how EVM should be working here. Once > EVM is initialised, all EVM attributes will be protected, making it > impossible to write new values to any xattrs covered by EVM unless > IMA_NEW_FILE is set. Up to now, security.evm has been to detect off line changes, not to prevent the running system's file meta-data from changing. Before the security.evm HMAC can be updated, the existing value must be verified. Otherwise any file metadata change would cause security.evm to be updated, including any off line modifications. Updating the security.evm HMAC is triggered by writing/updating the file's metadata (eg. setattr, setxattr, removexattr). > But as far as I can tell, IMA_NEW_FILE will only > be set if there's an IMA action that covers the file in question. This > means it's possible to write out security.evm and friends on newly > created files that would be appraised, but not on any other files. Am > I missing something? Only files in the IMA policy that pass integrity verification can be accessed. The IMA_NEW_FILE flag overides this restriction, allowing IMA to access new files, even if the security.ima xattr does not yet exist. Mimi
