On Thu, 2021-01-07 at 13:48 -0800, James Bottomley wrote: > On Thu, 2021-01-07 at 15:51 -0500, Mimi Zohar wrote: > > On Thu, 2021-01-07 at 12:37 -0800, James Bottomley wrote: > > > On Thu, 2021-01-07 at 15:02 -0500, Mimi Zohar wrote: > > > > On Thu, 2021-01-07 at 08:42 -0800, James Bottomley wrote: > [...] > > > > > What about having a log entry that's the current PCR > > > > > value? Then stretches of the log starting with these entries > > > > > would be independently verifiable provided you had a way of > > > > > trusting the PCR value. It might be possible to get the TPM to > > > > > add a signed quote as an optional part of the log entry (of > > > > > course this brings other problems like which key do you use for > > > > > the signing and how does it get verified) which would provide > > > > > the trust and would definitively allow you to archive log > > > > > segments and still make the rest of the log useful. > > > > > > > > The current PCR values are aggregated and stored in the > > > > boot_aggregate record. As part of the new boot_aggregate record > > > > format, the individual PCR values could be included. > > > > > > I don't think we care about the boot aggregate ... it's just the > > > initial log entry that ties the boot state to the initial runtime > > > state. All we need for the proposed entry is the current value of > > > the IMA PCR so provided you trust that value it becomes a base on > > > which the following measurements can build and be trusted. > > > > The IMA measurement list may contain multiple PCRs, not just the > > default IMA PCR. Each kexec results in an additional boot_aggregate > > record, but an equivalent record for after truncating the measurement > > list might help. > > Right, this would specifically be only of the IMA PCR so you can use it > as a base to begin the hash of the following log segment. The log can > still contain other boot aggregate entries, but the assumption is that > boot aggregate entries in the prior log have already been evaluated. IMA may be configured on a per rule basis to measure files into different PCRs. Between the previous boot aggregate record and truncating the measurement list, other PCRs may have been extended. > > > > > But this doesn't address where the offloaded measurement list > > > > will be stored, how long the list will be retained, nor who > > > > guarantees the integrity of the offloaded list. In addition, > > > > different form factors will have different requirements. > > > > > > I'm not sure you need any store at all. The basic idea is that the > > > log is divided into individually verifiable segments. For auditing > > > purposes you could keep all segments, so you have the entire log, > > > but if you've acted on the prior log entries and you don't have an > > > audit reason to keep them, you could erase that segment of the log > > > because you've placed all your trust in the prior log segments into > > > the PCR entry that forms the base of your current segment. > > > > > > Essentially the question devolves to what mechanisms can give you > > > this trust in the base PCR log entry. > > > > > > Not retaining the entire measurement list would limit it's verification > > to a single server/system. > > Well, it would limit its verification to just that log segment, yes. Verifying only the current log segment only makes sense, if the previous log segments were previously verified. > > I'm thinking in the cloud there are a couple of potential consumers: > > 1. The cloud monitor, which acts on the verified log, such as killing a > node for trying to execute an unverified binary or emailing the > guest owner. This type of consumer doesn't need the historical log, > they just need to verify the entries they haven't already seen and > act on them according to whatever policy they're given. > 2. The second type of cloud consumer is the audit case where the > aggregate hash is used to assure some auditor, some time after the > actual events, that the entire runtime of the VM was properly > monitored and the auditor wants to see the log or a segment of it > to prove the hash. > > Case 1 doesn't need historical storage, case 2 definitely does. I > think we should support both use cases particularly in the long running > scenario where we need to recover memory. Having verifiable log > segments seems to satisfy both cases, but what you do with the segments > would vary. As Ken previously pointed out, the attestation server itself can request only the new measurements. Mimi
