On Thu, 2017-09-28 at 14:13 -0700, Matthew Garrett wrote: > On Thu, Sep 28, 2017 at 1:12 PM, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote: > > Earlier this year there were discussions on defining a portable EVM > > signature, that could be included in software packages. > > > > The reason for including as much metadata as possible in the HMAC is > > to limit cut & paste attacks. For this reason, the portable data is > > only used in transmission, not on disk. > > The concern is that two identical copies of a file may exist, but with > different security contexts, and that not protecting the inode would > allow an attacker to copy the security metadata from one file onto the > other? This presumably only has meaning if they're on separate > filesystems, since otherwise the attacker could just delete one file > and hardlink the other to the former's location? I think that for our > purposes this isn't a big deal. 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. > > A new EVM type is defined that does not convert the EVM signature to > > an HMAC. > > > > Mikhail's patches: > > https://sourceforge.net/p/linux-ima/mailman/linux-ima-user/thread/2017 > > 0113072602.4ffaa30a@totoro/ > > That looks broadly like what we want, but I think there's some > advantage in maintaining the flexibility of choosing which information > is embedded. One additional option would be to allow userland to place > a restriction on which options *must* be present, ie local policy > could refuse to allow any signatures that didn't include a specific > set of metadata. This introduces a new level of complexity, which I'm not sure is warranted. > 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. Mimi
