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


     \ /
      Last update: 2011-12-05 22:03    [W:0.024 / U:93.600 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site