On Mon, 2017-11-20 at 09:59 -0500, Mimi Zohar wrote: > > When allowing local hashing, it's actually worse: during an offline > > attack, the attacker might not have access to the TPM and thus > > cannot > > easily update the EVM HMAC. During an online attack, the kernel > > will > > happily update that and the IMA hash for the attacker, resulting in > > a > > file that passes appraisal after a reboot. > > The assumption is that most files in the TCB are not changing and are > signed. Custom policies should require file signatures for these > files. > > Assuming that the private keys that are used to sign these files, as > well as the private key used for signing other keys added to the IMA > keyring, are stored off line, new files can not be signed. > > The number of mutable files in the TCB should be very limited, > probably < 20 files. Their usage can be constrained by MAC. I'm not sure what exactly "constrained by MAC" implies, but I suspect that these mutable files will be as important for the integrity of the TCB as everything else (<insert my systemd configuration file example again here>). Compromised is compromised, an installation cannot be "half compromised". So once the policy allows mutable files, a run-time exploit that bypasses the MAC can compromise the TCB permanently. > That said, IMA/IMA-appraisal is work in progress. There are still > measurement/appraisal gaps that need to be closed. One such example > are files read by interpreters and interpreted files. There have > been some initial proposals in this area. That's what brings us back to my initial question: are the current set of patches enough to make appraisal useful? Matthew seems to be optimistic that the answer is yes and I certainly don't want to discourage him especially as he's doing some actual work while I couldn't do that, but I remain a bit more skeptical. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.
