From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935903AbdADMtc (ORCPT ); Wed, 4 Jan 2017 07:49:32 -0500 Received: from mga14.intel.com ([192.55.52.115]:54366 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935848AbdADMsU (ORCPT ); Wed, 4 Jan 2017 07:48:20 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,459,1477983600"; d="scan'208";a="26027313" Date: Wed, 4 Jan 2017 14:48:15 +0200 From: Jarkko Sakkinen To: Jason Gunthorpe Cc: James Bottomley , linux-security-module@vger.kernel.org, tpmdd-devel@lists.sourceforge.net, open list Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager Message-ID: <20170104124815.jzwdx6ybojdgin5p@intel.com> References: <20170102132213.22880-1-jarkko.sakkinen@linux.intel.com> <1483374980.2458.13.camel@HansenPartnership.com> <20170102193320.trawto65nkjccbao@intel.com> <1483393248.2458.32.camel@HansenPartnership.com> <20170103135121.4kh3jld5gaq3ptj4@intel.com> <1483461370.2464.19.camel@HansenPartnership.com> <20170103214702.GC29656@obsidianresearch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170103214702.GC29656@obsidianresearch.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.6.2-neo (2016-08-21) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 03, 2017 at 02:47:02PM -0700, Jason Gunthorpe wrote: > On Tue, Jan 03, 2017 at 08:36:10AM -0800, James Bottomley wrote: > > > > I'm not sure about this. Why you couldn't have a very thin daemon > > > that prepares the file descriptor and sends it through UDS socket to > > > a client. > > > > So I'm a bit soured on daemons from the trousers experience: tcsd > > crashed regularly and when it did it took all the TPM connections down > > irrecoverably. I'm not saying we can't write a stateless daemon to fix > > most of the trousers issues, but I think it's valuable first to ask the > > question, "can we manage without a daemon at all?" I actually think > > the answer is "yes", so I'm interested in seeing how far that line of > > research gets us. > > There is clearly no need for a daemon to be involved when working on > simple tasks like key load and key sign/enc/dec actions, adding such a > thing only increases the complexity. > > If we discover a reason to have a daemon down the road then it should > work in some way where the user space can call out to the daemon over > a different path than the kernel. (eg dbus or something) > > > Do you have a link to the presentation? The Plumbers etherpad doesn't > > contain it. I've been trying to work out whether a properly set up TPM > > actually does need any protections at all. As far as I can tell, once > > you've set all the hierarchy authorities and the lockout one, you're > > pretty well protected. > > I think we should also consider TPM 1.2 support in all of this, it is > still a very popular peice of hardware and it is equally able to > support a RM. I'm not against considering TPM 1.2 support but getting both in the same patch set would be too much. > > So, in general, I'd prefer to see the unprivileged char dev hard > prevented by the kernel from doing certain things: > > - Wipe the TPM > - Manipulate the SRK, nvram, tpm flags, change passwords etc > - Read back the EK > - Write to PCRs > - etc. I rather have an ioctl where you can supply a list of CCs that you want to allow a client to do. /Jarkko > Even if TPM 2 has a stronger password based model, I still think the > kernel should hard prevent those sorts of actions even if the user > knows the TPM password. > > Realistically people in less senstive environments will want to use > the well known TPM passwords and still have reasonable safety in their > unprivileged accounts. > > Jason From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jarkko Sakkinen Subject: Re: [PATCH RFC 0/4] RFC: in-kernel resource manager Date: Wed, 4 Jan 2017 14:48:15 +0200 Message-ID: <20170104124815.jzwdx6ybojdgin5p@intel.com> References: <20170102132213.22880-1-jarkko.sakkinen@linux.intel.com> <1483374980.2458.13.camel@HansenPartnership.com> <20170102193320.trawto65nkjccbao@intel.com> <1483393248.2458.32.camel@HansenPartnership.com> <20170103135121.4kh3jld5gaq3ptj4@intel.com> <1483461370.2464.19.camel@HansenPartnership.com> <20170103214702.GC29656@obsidianresearch.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20170103214702.GC29656-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tpmdd-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Jason Gunthorpe Cc: James Bottomley , linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, open list List-Id: tpmdd-devel@lists.sourceforge.net On Tue, Jan 03, 2017 at 02:47:02PM -0700, Jason Gunthorpe wrote: > On Tue, Jan 03, 2017 at 08:36:10AM -0800, James Bottomley wrote: > > > > I'm not sure about this. Why you couldn't have a very thin daemon > > > that prepares the file descriptor and sends it through UDS socket to > > > a client. > > > > So I'm a bit soured on daemons from the trousers experience: tcsd > > crashed regularly and when it did it took all the TPM connections down > > irrecoverably. I'm not saying we can't write a stateless daemon to fix > > most of the trousers issues, but I think it's valuable first to ask the > > question, "can we manage without a daemon at all?" I actually think > > the answer is "yes", so I'm interested in seeing how far that line of > > research gets us. > > There is clearly no need for a daemon to be involved when working on > simple tasks like key load and key sign/enc/dec actions, adding such a > thing only increases the complexity. > > If we discover a reason to have a daemon down the road then it should > work in some way where the user space can call out to the daemon over > a different path than the kernel. (eg dbus or something) > > > Do you have a link to the presentation? The Plumbers etherpad doesn't > > contain it. I've been trying to work out whether a properly set up TPM > > actually does need any protections at all. As far as I can tell, once > > you've set all the hierarchy authorities and the lockout one, you're > > pretty well protected. > > I think we should also consider TPM 1.2 support in all of this, it is > still a very popular peice of hardware and it is equally able to > support a RM. I'm not against considering TPM 1.2 support but getting both in the same patch set would be too much. > > So, in general, I'd prefer to see the unprivileged char dev hard > prevented by the kernel from doing certain things: > > - Wipe the TPM > - Manipulate the SRK, nvram, tpm flags, change passwords etc > - Read back the EK > - Write to PCRs > - etc. I rather have an ioctl where you can supply a list of CCs that you want to allow a client to do. /Jarkko > Even if TPM 2 has a stronger password based model, I still think the > kernel should hard prevent those sorts of actions even if the user > knows the TPM password. > > Realistically people in less senstive environments will want to use > the well known TPM passwords and still have reasonable safety in their > unprivileged accounts. > > Jason ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot