Messages in this thread |  | | | Date | Tue, 06 Dec 2011 11:27:33 +0100 | | From | Roberto Sassu <> | | Subject | Re: [PATCH 1/2] ima: split ima_add_digest_entry() function |
| |
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
> Mimi >
|  |