linux-kernel - Re: [PATCH 1/2] ima: split ima_add_digest

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1323118629.2061.117.camel@falcor>
Date:	Mon, 05 Dec 2011 15:57:08 -0500
From:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:	Roberto Sassu <roberto.sassu@...ito.it>
Cc:	Rajiv Andrade <srajiv@...ux.vnet.ibm.com>,
	linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org, jmorris@...ei.org
Subject: Re: [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:
> >>
> >> 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

--
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/