Re: [PATCH 1/2] ima: split ima_add_digest_entry() function

[Roberto Sassu <roberto.sassu@polito.it>]

On 12/05/2011 09:57 PM, Mimi Zohar wrote:
> On Mon, 2011-12-05 at 14:56 +0100, Roberto Sassu wrote:
>> On 12/05/2011 02:03 PM, Mimi Zohar wrote:
>>> On Mon, 2011-12-05 at 11:04 +0100, Roberto Sassu wrote:
>>>
>>>> Hi Mimi
>>>>
>>>> i think moving this logic to the TPM driver (or in general, delaying
>>>> the action after the list mutex is unlocked) is not safe, because in
>>>> this way you are relying on the kernel trustworthiness to protect
>>>> itself and IMA against unmeasured potential attacks. So, the verifier
>>>> is unable to detect a kernel tampering that removed the limitation
>>>> on the TPM Quote operation.
>>>>
>>>> What i'm proposing in the patch:
>>>>
>>>> https://lkml.org/lkml/2011/11/21/202
>>>>
>>>> is in fact a new extension, which is triggered by a new kernel
>>>> parameter, so that the behaviour of the base IMA is not modified.
>>>
>>> How/why the TPM fails is important.  If the TPM fails because of an
>>> intermittent problem, then your solution of denying read/execute could
>>> work, but what would happen if it was persistent?  Would you be able to
>>> quiesce the system?
>>>
>>> As there is no way of differentiating a persistent from intermittent
>>> failure, both need to be addressed in the same manor.  For persistent
>>> TPM failure, we can not access the TPM to modify the PCR.  So what
>>> options do we have left?  My suggestion, though not optimal, prevents
>>> the IMA PCR from being quoted.
>>>
>>
>> Hi Mimi
>>
>> the solution you are proposing is reasonable as the default
>> behaviour, because not all IMA users need the high confidence
>> in the measurements, as ensured by denying the execution of
>> system calls.
>>
>> However, during the IMA initialization the TPM is tested
>> by issuing a PCR read (the test procedure may be extended
>> to better detect existing errors in advance). So, this means
>> that a TPM failure when the system is already powered on is
>> very unlikely and may cause serious issues as it could happen
>> if other devices are involved.
>>
>> For this reason, also my extension seems helpful especially
>> in the situations where all events need to be measured properly.
>> In this case, IMA users are aware that a TPM failure could hang
>> their systems, because they need to manually insert the required
>> kernel parameter.
>
> As you said a TPM failure is very unlikely, what type of attack are you
> trying to defend against, that could possibly warrant causing the system
> to hang?
>

I don't know if this can really happen, but an attacker may issue
a lot of commands to the TPM, so that the timeout limit is reached
when IMA is trying to extend the PCR.

Roberto Sassu


> Mimi
>