Messages in this thread | | | Date | Thu, 2 Dec 2021 13:03:03 -0500 | Subject | Re: [RFC 08/20] ima: Move measurement list related variables into ima_namespace | From | Stefan Berger <> |
| |
On 12/2/21 12:44, James Bottomley wrote: > On Thu, 2021-12-02 at 11:45 -0500, Stefan Berger wrote: >> On 12/2/21 11:29, James Bottomley wrote: >>> On Thu, 2021-12-02 at 08:41 -0500, Stefan Berger wrote: >>>> On 12/2/21 07:46, James Bottomley wrote: >>>>> On Tue, 2021-11-30 at 11:06 -0500, Stefan Berger wrote: >>>>>> Move measurement list related variables into the >>>>>> ima_namespace. >>>>>> This >>>>>> way a >>>>>> front-end like SecurityFS can show the measurement list >>>>>> inside an >>>>>> IMA >>>>>> namespace. >>>>>> >>>>>> Implement ima_free_measurements() to free a list of >>>>>> measurements >>>>>> and call it when an IMA namespace is deleted. >>>>> This one worries me quite a lot. What seems to be happening in >>>>> this >>>>> code: >>>>> >>>>>> @@ -107,7 +100,7 @@ static int ima_add_digest_entry(struct >>>>>> ima_namespace *ns, >>>>>> qe->entry = entry; >>>>>> >>>>>> INIT_LIST_HEAD(&qe->later); >>>>>> - list_add_tail_rcu(&qe->later, &ima_measurements); >>>>>> + list_add_tail_rcu(&qe->later, &ns->ima_measurements); >>>>>> >>>>>> atomic_long_inc(&ns->ima_htable.len); >>>>>> if (update_htable) { >>>>>> >>>>> is that we now only add the measurements to the namespace list, >>>>> but >>>>> that list is freed when the namespace dies. However, the >>>>> measurement >>>>> is still extended through the PCRs meaning we have incomplete >>>>> information for a replay after the namespace dies? >>>> *Not at all.* The measurement list of the namespace is >>>> independent >>>> of >>>> the host. >>>> >>>> The cover letter states: >>> I get that the host can set up a policy to log everything in the >>> namespace, but that wasn't my question. My question is can the >>> guest >>> set up a policy to log something that doesn't go into the host log >>> (because the host hasn't asked for it to be logged) but extends a >>> PCR >>> anyway, thus destroying the ability of the host to do log replay. >> host log goes with host TPM and vice versa >> >> guest log goes with (optional) vTPM and vice version > But that's what doesn't seem to happen ... ima_pcr_extend isn't > virtualized and it's always called from ima_add_template_entry() > meaning the physical TPM is always extended even for a namespace only > entry.
You cannot set a measurement rule in the namespace. That is prevented per 9/20: ima: Only accept AUDIT rules for IMA non-init_ima_ns namespaces for now.
Also, with the tests that I have done with IMA namespaces I have not seen any 'evmctl ima_measurement ...' failures.
Have you been able to cause the IMA namespace to do measurements? It would be an easy thing to move the tpm_chip into the ima_namespace as well, but per 9/20 this shouldn't be necessary at this point.
> > >> Extending the PCR of the host's TPM would require the data to be >> logged in the host log as well. So, no, it's not possible. > Well, exactly: if you don't have or want a vTPM per container the only > way to attest is via the physical TPM which means all entries in the > namespace must be in the host log, so the host owner can quote and > reply and they can split the attested log and give assurance to the > namespaces that their entries are correct.
Yes, this series allows you to log into the system log and along with this extend the TPM PCR.
> > James > >
| |