On Thu, Sep 28, 2017 at 5:53 PM, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote: > Without the inode included in the HMAC calculation, the same file > could exist as a different file name on the same file system. No need > for the two files to be on different file systems. But if I create a hardlink to an existing file then I get the same file with the same inode number and two different names on the same filesystem, and so security.evm would still match? >> One of the reasons we're interested in allowing the use of signatures >> rather than HMACs is to avoid the case where a machine being >> compromised would allow an attacker to obtain the symmetric key and >> drop new appropriately HMACed binaries on the system that would >> persist even if the kernel was updated to fix the vulnerability. > > Assuming you're using a trusted key (TPM based key) to encrypt/decrypt > the EVM key (trusted key), then such an attack would require root > privileges with the ability to read kernel memory. The EVM key is > never exposed to userspace in the clear. That's a case that we need to be worried about. Trusted boot means we can ensure that a system boots an updated kernel, but if the attacker has been able to drop a modified sshd with a valid hmac onto the system then we have fewer guarantees about the integrity. We could continue using signatures for security.ima to avoid that, but then we lose the performance benefits of the hmac and also don't have the same level of guarantees around the other security metadata.
