| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <4EDF7812.3070506@polito.it> Date: Wed, 07 Dec 2011 15:28:34 +0100 From: Roberto Sassu <roberto.sassu@...ito.it> To: "Kasatkin, Dmitry" <dmitry.kasatkin@...el.com> CC: Mimi Zohar <zohar@...ux.vnet.ibm.com>, 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 12/07/2011 02:33 PM, Kasatkin, Dmitry wrote: > On Tue, Dec 6, 2011 at 4:50 PM, Roberto Sassu<roberto.sassu@...ito.it> wrote: >> On 12/06/2011 03:24 PM, Mimi Zohar wrote: >>> >>> 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. >>> >> >> I mean issuing a lot of TPM commands, so that the TPM is unable >> to process the IMA request. >> >> >> >>> So the issue remains whether an individual PCR extend can timeout/fail. >>> As you previously said, this is highly unlikely. >>> >> >> I think the question is whether or not an attacker can cause the >> TPM to reach the timeout limit. If this is feasible and it cannot >> be clearly detected by inspecting the measurements list, denying >> the system call for which the measurement cannot be taken may be a solution. >> >> Roberto Sassu >> >> >> >>> Mimi >>> > > If TPM is a separate HW module, it is often possible to make HW attack > and modify parameters and return values, > by accessing the bus. > Hi Dmitry yes, this is another class of attacks that may also be used to delay the execution of a command, so that the timeout limit will be reached. However, probably we can do nothing if an attacker can modify parameters or return values by accessing the hardware. Roberto Sassu > - Dmitry > >> >> -- >> To unsubscribe from this list: send the line "unsubscribe >> linux-security-module" in >> the body of a message to majordomo@...r.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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