Messages in this thread | | | Subject | Re: [PATCH 1/2] ima: split ima_add_digest_entry() function | From | Mimi Zohar <> | Date | Mon, 05 Dec 2011 15:57:08 -0500 |
| |
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?
Mimi
| |