Message-ID: <1323181487.2165.35.camel@falcor>
Date:	Tue, 06 Dec 2011 09:24:46 -0500
From:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:	Roberto Sassu <roberto.sassu@...ito.it>
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 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.

So the issue remains whether an individual PCR extend can timeout/fail.
As you previously said, this is highly unlikely.

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/

Powered by blists - more mailing lists