Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Andreas Fuchs <andreas.fuchs@sit.fraunhofer.de>
Cc: James Bottomley <jejb@linux.vnet.ibm.com>,
	"linux-security-module@vger.kernel.org" 
	<linux-security-module@vger.kernel.org>,
	"tpmdd-devel@lists.sourceforge.net" 
	<tpmdd-devel@lists.sourceforge.net>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager
Date: Fri, 6 Jan 2017 12:10:49 -0700	[thread overview]
Message-ID: <20170106191049.GA19576@obsidianresearch.com> (raw)
In-Reply-To: <f5c8f4a2-d4ad-a2a0-9443-26589c58f9a7@sit.fraunhofer.de>

On Fri, Jan 06, 2017 at 09:59:57AM +0100, Andreas Fuchs wrote:

> 1. PolicyPCR is an essential feature of TPM used all over the place,
> so we need support for policy sessions.
> 2. PolicySigned allows authentication of the user via SmartCard.

Are smart cards 0666 in linux?

> The all-defeating reason for having in-kernel-RM is trusted keyrings
> or IMA/EVM appraise/protect or similar. They will want to use sealing
> to PCRs which in turn requires policy sessions from inside the kernel
> and thus RM inside the kernel to play nicely with the TSS.

Yes. I had hoped the in-kernel-RM could also provide safe 0666 access,
but lets move on from that idea and focus on kernel/user TPM
application co-existence...

> And IMHO nobody wants the kernel security modules to call back to a
> userspace RM-daemon.

Yep.

> If everyone agrees with this presumption the only question becomes
> how to do this, such that we don't need a second RM in userspace
> for the 99% of use cases.

Yep.

> P.S. This fact should also be given some thought when discussing the
> priviledged 0600 node, i.e. /dev/tpm0 without the s in the middle.

We are stuck with the non-RM interface for compat. There could be a
kernel option/module option/sysctl/whatever of some kind to disable it
I guess.

Jason