On Fri, 2017-09-29 at 11:09 -0700, Matthew Garrett wrote: > 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? True, with a hard link that would be the case, but by the same file, I meant a copy of the original file, not a hard link to the file. > >> 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. I think you mean "secure boot", not "trusted boot", in this case. The original understanding was that IMA/EVM would enforce integrity and not enforce mandatory access control (MAC). The LSMs (eg. SELinux) would be responsible for MAC. Separation of duties. With that understanding, if the LSM allows a file to be "dropped" onto the file system of a running system, IMA/EVM will hash and hmac the permitted file. I don't understand where you're going with this train of thought. If you're trying to make a case for EVM to run with only security.evm signatures, then you wouldn't refer to the HMAC benefits. If you're trying to make a case for EVM signatures, with the inode they're not portable, without the inode, they are susceptible to a cut and paste attack. Mickhail's proposed patches resolves this by having a portable EVM signature that is never written to disk, but converted to an HMAC. Mimi
