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

[Kasatkin, Dmitry]

On Tue, Dec 6, 2011 at 4:50 PM, Roberto Sassu <roberto.sassu@xxxxxxxxx> wrote:
> On 12/06/2011 03:24 PM, Mimi Zohar wrote:
>>
>> On Tue, 2011-12-06 at 11:27 +0100, Roberto Sassu wrote:
>>>
>>> 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
>>
>>
>> Processing lots of commands isn't an issue, as IMA takes the
>> ima_extend_list_mutex to synchronize adding the measurement to the
>> measurement list and extending the PCR. ÂThe TPM device driver takes the
>> tpm_mutex, in tpm_transmit(), before transmitting the command.
>>
>
> I mean issuing a lot of TPM commands, so that the TPM is unable
> to process the IMA request.
>
>
>
>> So the issue remains whether an individual PCR extend can timeout/fail.
>> As you previously said, this is highly unlikely.
>>
>
> I think the question is whether or not an attacker can cause the
> TPM to reach the timeout limit. If this is feasible and it cannot
> be clearly detected by inspecting the measurements list, denying
> the system call for which the measurement cannot be taken may be a solution.
>
> Roberto Sassu
>
>
>
>> Mimi
>>

If TPM is a separate HW module, it is often possible to make HW attack
and modify parameters and return values,
by accessing the bus.

- Dmitry

>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-security-module" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at Âhttp://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/