[lkml]   [2011]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/2] ima: split ima_add_digest_entry() function
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:
>>>> 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

 \ /
  Last update: 2011-12-06 11:31    [W:0.068 / U:4.708 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site