linux-kernel - Re: [PATCH 1/2] ima: split ima_add_digest

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4EDE2BC8.9080109@polito.it>
Date:	Tue, 06 Dec 2011 15:50:48 +0100
From:	Roberto Sassu <roberto.sassu@...ito.it>
To:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
CC:	Rajiv Andrade <srajiv@...ux.vnet.ibm.com>,
	linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org, jmorris@...ei.org,
	Kenneth Goldman <kgoldman@...ibm.com>
Subject: Re: [PATCH 1/2] ima: split ima_add_digest_entry() function

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
>

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