On Tue, 2019-06-11 at 08:22 -0400, Mimi Zohar wrote: > On Fri, 2019-06-07 at 10:15 -0700, Lakshmi wrote: > > On 6/7/19 7:14 AM, Ken Goldman wrote: > > > > > > > > Why is this important? What is gained by measuring the keys on the > > > built-in keyring? The IMA log already measures [a pointer to] the > > > IMA keys used for signature verification. Why does the service care > > > what keys were used to install the IMA keys? > > > > By measuring the built-in keyring, the service knows whether or not the > > key(s) in "IMA keyring" are indeed trusted or not. So while the IMA key > > validates the file signatures on the client, the built-in key validates > > the IMA key(s). > > > > By knowing what keys were used to install the IMA key(s) the service > > knows whether or not to trust the signature validation performed by IMA > > on the client. > > > > > > > > I don't understand this reasoning. > > > > > > To me, there is a difference between signed files and trusted files. > > > E.g., an old version may be signed, but it is no longer trusted. > > > > In other words, the service wants to know all files that have run, not > > > just whether they are signed. > > > > The service will receive the entire IMA log - the entries that show what > > system files were loaded, the IMA signature, etc. My change additionally > > provides measurement on the signer (which key(s) were used to install > > the keys in IMA keyring). Together this data enables the service to > > determine whether the files on the client were signed and who the signer > > is. The service can then decide whether the client is running files that > > are trusted. > > > > > > > > Further, the service also wants to know files that were blocked from > > > running, either because of no signature, a signature with an untrusted > > > IMA key, or a bad signature. I.e., the service needs the entire IMA > > > log, not just the keys used to install the keys used to locally verify > > > the signatures. > > > > Like I have stated above, the change I am making is adding more data > > (information on built-in keys) to what IMA log already provides". > > > > My proposal is not to replace the current IMA log with just data on > > "built-in keys". > > > > Also, want to clarify that we do not want the service to also locally > > verify the signatures. To do that the service needs to maintain the > > signed file hashes of all the files and all the versions of each of > > those files - That is an high overhead approach. > > > > Instead, we let the client do the signature validation and on the > > service just validate who signed those files. > > > > > > > > While the built-in keys may change less frequently that the IMA keys, > > > both are likely to be stable. I.e., is this proposal to provide an > > > additional security benefit, or is it to improve performance? > > > > The proposal enables the service to validate that the file signature of > > the files on the client were created by "trusted signer". So it provides > > additional security benefit and at the same time reduces the maintenance > > overhead in the service - by enabling it to just keep track of "Known > > good trusted keys" which change less frequently. > > > > I hope I have answered all of your questions\concerns. > > The design of IMA from the very beginning has been to allow the system > owner to decide which keys to trust. This is the reason that the root > of trust pivots from the pre-boot keys to the keys embedded in the > Linux kernel. When software packages contain both the file data and > file signatures, the system owner will be able to pick and choose > which public keys to sign and load onto the IMA keyring. > > This patch set might not be limiting which public keys may be loaded > onto the builtin/secondary keyrings, but by virtue of including this > information in the measurement list, the attestation service (eg. TNC) > will be able to deny access. IMA walks a fine line in enforcing and > measuring file integrity. This patch set breaches that fine line and > by so doing, brings back the fears of trusted computing. Many attempts over the years were made to update grub to support secure & trusted boot. Richard Stallman (grudgingly) added the secure boot callbacks, which are also being used for trusted boot. The code to actually do the signature verification though, as far as I'm aware, is still not part of grub. It also took a really long time and effort to convince Stallman that TPMs aren't totally bad. He's added an addendum to the wiki.[1] Let's try not to upset Stallman too much. Mimi [1] https://www.gnu.org/philosophy/can-you-trust.en.html
