Messages in this thread |  | | | Subject | Re: [PATCH 04/14] evm: re-release | | From | Mimi Zohar <> | | Date | Fri, 04 Jun 2010 10:53:32 -0400 |
| |
On Fri, 2010-06-04 at 10:28 -0400, Stephen Smalley wrote: > 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?
This changed very early on, so that people without a TPM could 'play' with it.
Mimi
|  |