From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934116AbdABVlC (ORCPT ); Mon, 2 Jan 2017 16:41:02 -0500 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:59144 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756006AbdABVk6 (ORCPT ); Mon, 2 Jan 2017 16:40:58 -0500 Message-ID: <1483393248.2458.32.camel@HansenPartnership.com> Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager From: James Bottomley To: Jarkko Sakkinen Cc: linux-security-module@vger.kernel.org, tpmdd-devel@lists.sourceforge.net, open list Date: Mon, 02 Jan 2017 13:40:48 -0800 In-Reply-To: <20170102193320.trawto65nkjccbao@intel.com> References: <20170102132213.22880-1-jarkko.sakkinen@linux.intel.com> <1483374980.2458.13.camel@HansenPartnership.com> <20170102193320.trawto65nkjccbao@intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2017-01-02 at 21:33 +0200, Jarkko Sakkinen wrote: > On Mon, Jan 02, 2017 at 08:36:20AM -0800, James Bottomley wrote: > > On Mon, 2017-01-02 at 15:22 +0200, Jarkko Sakkinen wrote: > > > This patch set adds support for TPM spaces that provide a context > > > for isolating and swapping transient objects. This patch set does > > > not yet include support for isolating policy and HMAC sessions > > > but it is trivial to add once the basic approach is settled (and > > > that's why I created an RFC patch set). > > > > The approach looks fine to me. The only basic query I have is > > about the default: shouldn't it be with resource manager on rather > > than off? I can't really think of a use case that wants the RM off > > (even if you're running your own, having another doesn't hurt > > anything, and it's still required to share with in-kernel uses). > > This is a valid question and here's a longish explanation. > > In TPM2_GetCapability and maybe couple of other commands you can get > handles in the response body. I do not want to have special cases in > the kernel for response bodies because there is no a generic way to > do the substitution. What's worse, new commands in the standard > future revisions could have such commands requiring special cases. In > addition, vendor specific commans could have handles in the response > bodies. OK, in general I buy this ... what you're effectively saying is that we need a non-RM interface for certain management type commands. However, let me expand a bit on why I'm fretting about the non-RM use case. Right at the moment, we have a single TPM device which you use for access to the kernel TPM. The current tss2 just makes direct use of this, meaning it has to have 0666 permissions. This means that any local user can simply DoS the TPM by running us out of transient resources if they don't activate the RM. If they get a connection always via the RM, this isn't a worry. Perhaps the best way of fixing this is to expose two separate device nodes: one raw to the TPM which we could keep at 0600 and one with an always RM connection which we can set to 0666. That would mean that access to the non-RM connection is either root only or governed by a system set ACL. James