Re: IMA appraisal master plan?

[Patrick Ohly <patrick.ohly@intel.com>]

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.