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]

Date:	Wed, 16 Nov 2011 16:52:50 -0200
From:	Rajiv Andrade <srajiv@...ux.vnet.ibm.com>
To:	Roberto Sassu <roberto.sassu@...ito.it>
CC:	Mimi Zohar <zohar@...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


Thanks, Rajiv Andrade Security Development IBM Linux Technology Center

On 16-11-2011 12:37, Roberto Sassu wrote:
> On 11/16/2011 02:38 PM, Mimi Zohar wrote:
>> On Wed, 2011-11-16 at 11:10 +0100, Roberto Sassu wrote:
>>> The ima_add_digest_entry() function has been split in order to avoid
>>> adding an entry in the measurements list for which the PCR extend
>>> operation subsequently fails. Required memory is allocated earlier 
>>> in the
>>> new function ima_prepare_template_entry() and the template entry is 
>>> added
>>> after ima_pcr_extend().
>>>
>>> Signed-off-by: Roberto Sassu<roberto.sassu@...ito.it>
>>
>
> Hi Mimi
>
> i don't know if this condition can happen, but suppose that
> for whatever reason the PCR extend fails. In this case, since
> the PCR is not extended, the measurements list can be modified,
> by removing the non-measured entry, without this fact being
> detected by the verifier. So, probably we can avoid to display
> the entry.
>
>
Hi Roberto,

IMA's trustworthiness is built on the assumption that the TPM underneath can
be trusted. If that can't be, the eventlog alone doesn't provide us any 
security.
It's the TPM device driver's job though to workaround any HW bug so that 
in the
end all its stakeholders have their commands processed successfully, as 
we've
pursued in some changes here:

http://marc.info/?l=linux-kernel&m=132144742019589&w=2 
<http://marc.info/?l=linux-kernel&m=132144742019589&w=2>

What you're doing is to indeed move part of that trust to the software 
stack,
assuming that in case the TPM fails to process a command, you could fall 
back to
the event log anyways. It isn't a matter of it's a right or wrong 
software engineering
decision, but inside the trusted computing scope, it breaks the model.

Rajiv

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