From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756890Ab1KRK10 (ORCPT ); Fri, 18 Nov 2011 05:27:26 -0500 Received: from mail-ey0-f174.google.com ([209.85.215.174]:61627 "EHLO mail-ey0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751903Ab1KRK1X (ORCPT ); Fri, 18 Nov 2011 05:27:23 -0500 Message-ID: <4EC63302.4040006@polito.it> Date: Fri, 18 Nov 2011 11:27:14 +0100 From: Roberto Sassu Organization: Politecnico di Torino User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mimi Zohar CC: Rajiv Andrade , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, jmorris@namei.org Subject: Re: [PATCH 1/2] ima: split ima_add_digest_entry() function References: <1321438229-18925-1-git-send-email-roberto.sassu@polito.it> <1321450690.1901.24.camel@falcor> <4EC3CA9A.3070401@polito.it> <4EC40682.2050602@linux.vnet.ibm.com> <4EC4E89F.2060608@polito.it> <1321564518.21708.63.camel@falcor> In-Reply-To: <1321564518.21708.63.camel@falcor> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/17/2011 10:15 PM, Mimi Zohar wrote: > On Thu, 2011-11-17 at 11:57 +0100, Roberto Sassu wrote: >> On 11/16/2011 07:52 PM, Rajiv Andrade wrote: >>> >>> 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 >>>>> >>>> >>>> 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: >>> >> >> Hi Rajiv >> >> thanks for your comments. >> >> I absolutely agree that we have to trust the TPM for the correct >> execution of IMA. >> >> I think the principle that has been used to build IMA (according >> to the TGC specifications) is that we can trust the eventlog >> as long as the measurement infrastructure is reliable or it is >> possible to detect a threat from previous measurements. >> >> For this reason, a system call is never executed before the >> inode measurement is inserted in the eventlog and the PCR >> is extended. Since these operations must be considered as >> atomic, their execution is protected by a mutex, that is >> released only after all tasks have been performed. This >> ensures that we begin with a measured kernel and we can >> reliably measure all further interactions. This also explains, >> in my view, why delaying the PCR extend operation may lead >> to security risks. >> >> About my patch, i did not move out the protected region any >> of the above described operations. Instead, i'm preventing >> measurements for which the PCR extend failed to be added to >> the measurements list, because in any case it is impossible >> for a verifier to detect their removal from the list. >> >> As i mentioned in the previous mail, one solution to overcome >> this issue is to deny, on the platform running IMA, the execution >> of those system calls for which the measurement process ended >> with an error. >> >> Regards >> >> Roberto Sassu > > True, if the TPM failed to extend the PCR, a malicious user would be > able to remove the measurement from the measurement list without it > being detected. However, according to the TPM specs, the PCR extend > operation is always suppose to succeed, even in the case when the TPM is > not enabled. > Hi Mimi i don't know if this can happen, but, since the TPM always returns a result in its response, there may be particular conditions under which the PCR extend fails. After quickly looking at the code in 'drivers/char/tpm.c' there are some additional cases where the operation may fail. For instance, an operation may have been cancelled or it may have just reached the defined time limit. > More importantly we need to be able to detect when the PCR has not been > extended appropriately in order to address it. Otherwise we're just > covering it up. > Probably i did not understand this point, but do the return code of tpm_pcr_extend() is not sufficient to determine if the operation was completed successfully? Roberto Sassu > thanks, > > Mimi >