lkml.org 
[lkml]   [2011]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 1/2] ima: split ima_add_digest_entry() function
    From
    Date
    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



    \
     
     \ /
      Last update: 2011-12-06 15:29    [W:0.029 / U:68.236 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site