Messages in this thread |  | | | Subject | Re: [PATCH 04/14] evm: re-release | | From | Stephen Smalley <> | | Date | Fri, 04 Jun 2010 10:28:50 -0400 |
| |
On Wed, 2010-04-21 at 17:49 -0400, Mimi Zohar wrote: > EVM protects a file's security extended attributes against integrity > attacks. It maintains an HMAC-sha1 value across the extended attributes, > storing the value as the extended attribute 'security.evm'. EVM has gone > through a number of iterations, initially as an LSM module, subsequently > as a LIM integrity provider, and now, when co-located with a security_ > hook, embedded directly in the security_ hook, similar to IMA. > > This is the first part of a local file integrity verification system. > While this part does authenticate the selected extended attributes, and > cryptographically bind them to the inode, coming extensions will bind > other directory and inode metadata for more complete protection. The > set of protected security extended attributes is configured at compile. > > EVM depends on the Kernel Key Retention System to provide it with the > kernel master key for the HMAC operation. The kernel master key is > securely loaded onto the root's keyring, typically by 'loadkernkey', > which either uses the TPM sealed secret key, if available, or a > password requested from the console. To signal EVM, that the key has > been loaded onto the keyring, 'echo 1 > <securityfs>/evm'. This is > normally done in the initrd, which has already been measured as part > of the trusted boot. (Refer to http://linux-ima.sourceforge.net/#EVM.)
I don't remember this dependency on the kernel key system in prior incarnations of EVM. Can you explain the rationale for using it, and the implications?
-- Stephen Smalley National Security Agency
|  |