IMA appraisal master plan?

[Mimi Zohar]

On Mon, 2017-11-20 at 11:20 +0100, Patrick Ohly wrote:
> On Mon, 2017-11-20 at 07:47 +1100, James Morris wrote:
> > On Fri, 17 Nov 2017, Roberto Sassu wrote:
> > 
> > > LSMs are responsible to enforce a security policy at run-time,
> > > while IMA/EVM protect data and metadata against offline attacks.
> > 
> > In my view, IMA can also protect against making an online attack 
> > persistent across boots, and that would be the most compelling use of
> > it for many general purpose applications.
> 
> I do not quite buy that interpretation. If the online attack succeeds
> in bypassing the run-time checks, for example with a full root exploit,
> then he has pretty much the same capabilities to make persistent file
> changes as during an offline attack.

In the face of a full root exploit, there is not much that one can do,
"other" than to detect it.  This is why remote attestation is so
important.

> 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.

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.

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html