On Wed, Mar 6, 2019 at 2:39 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > On Wed, 2019-03-06 at 10:31 -0800, Matthew Garrett wrote: > > Ok. Would annotating the audit message to indicate that the hash was > > provided directly by the filesystem be sufficient? > > The audit log doesn't have the same security properties as the TPM > quote and IMA measurement list. Nor does the attestation server > necessarily have access to it. Ok. > > I'm not clear on > > why an admin would set this flag without having read the documentation > > for it - like many security features, enabling an inappropriate > > combination of them may result in bad things happening. I'm not keen > > on tying it to signing because: > > > > a) There are multiple configurations where requiring signed policy > > doesn't give a security benefit - if the IMA policy is part of a > > verified or measured initramfs, we already have integrity guarantees > > and adding an additional layer of signing doesn't win us anything (eg, > > in this configuration the IMA key may be loaded from the initramfs as > > well, so an attacker able to modify policy could add an additional > > signing key). > > Agreed, as long as there is no possibility of additional files being > installed/downloaded to the rootfs or files on other filesystems being > accessed before the IMA keyring is locked or a custom policy is > installed, a verified or measured initramfs might be enough. > > This implies that both the custom policy and the keys loaded onto the > IMA keyring are included in the initramfs, which isn't what is > currently being done today. My preference would be to remove the > original method of loading unsigned IMA policies, but that could/would > break existing systems. It's the way we handle IMA configuration - the policy is loaded and further policy loads are disabled due to IMA_WRITE_POLICY being default n. We're not currently making use of signing, but longer term plan is for the keys to be loaded at the same time. > > b) Users who are already using signed policy won't get the additional > > hint that you think is necessary. > > But they would have to knowingly add "get_hash" to the IMA policy and > have signed it. But in the non-signed case they'd still need to knowingly add "get_hash" to the IMA policy. Why does signing indicate stronger understanding of policy? If my understanding of ima_match_policy() correct, if there's already a measurement rule that applies to a filesystem then adding an additional trust_vfs rule will be ignored, so once the initial policy is loaded it's not possible for someone to transition a filesystem from a full read to using the vfs call. IE, a policy like: measure measure fsmagic=0x46555345 trust_vfs is still going to perform the full measurement even on FUSE. > > I'm happy to add this if there's a real threat model around it, but > > requiring signing for something other than security reasons seems like > > it's conflating unrelated issues. > > A colleague said, relying on the filesystem to provide the file hash > extends the TCB to include filesystems. The TCB already includes filesystems - IMA's measurements are only accurate if the filesystem returns the same data on subsequent reads (assuming i_version hasn't been updated). We assert that this is true, but it the filesystem is outside the TCB then that assertion is invalid.
