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: <4EDDEE15.3090200@polito.it>
Date:	Tue, 06 Dec 2011 11:27:33 +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
Subject: Re: [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:
>>>>
>>>> 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
>

--
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/