On 6/10/2019 12:57 PM, Jordan Hand wrote:
Thought I'd jump in this conversation to see if I can clarify what I see
as the value of this patch set.
At a certain point, keeping a list of all known-good (or known-bad)
hashes becomes infeasible. We could probably disagree about at what
scale this happens but I think we could agree that eventually this
happens (let me know if you still disagree with this assertion). So at
this point you likely need to rely on a few things:
I've seen large systems with 60,000 measurements. Even if that goes to
100,000, *10 for bad measurements, and *10 for future expansion, that's
only 10M, or 320 mbytes. That's pennies of disk space.
(1) is the file >= <known good version>. This allows you to forbid any
kernel version before a vulnerability was fixed.
Perhaps, but one might also exclude a newer version, either because of a
regression, a certification, etc.
(2) Was it signed with a good, trusted, production key.
You can sort of do this today by using the keyid. The issues with this
are (a) collision (though the chance may be pretty remote. I don't have
the crypto expertise to make an empirical call on that) and (b) you need
to know all the possible signing keys in the service.
The 4 byte key id was probably a long term mistake, but can be fixed.
Today, a collision is remote. Even then, just try both keys. Nothing
breaks.
Again, once you cross a certain scale threshold, signing/deployment is
so automated that the leaf key could change at any time, leaving your
service in the dark about new keys. You could automatically add new
trusted keys to the service but it depends on the service environment
and how much you want to automate what the service trusts.
So what does measuring the keyring do? It allows you to put long-lived
trusted CAs in .builtin_trusted_keys. On the service if you trust the CA
and you trust the running kernel to do the right thing during key
enrollment, you can trust that loaded files are properly signed.
This is my gap in understanding.
Even if I somewhat trust the keys on the built-in keyring, I may not
trust every key on the IMA keyring.
I may trust the kernel that ran at the time the key was enrolled, but I
don't trust the one that's currently running until I attest. Or, are
all the keys on both keyrings erased before any kernel SW update? I
don't think so.
