From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752590AbdAZLOQ (ORCPT ); Thu, 26 Jan 2017 06:14:16 -0500 Received: from mga06.intel.com ([134.134.136.31]:58605 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752029AbdAZLON (ORCPT ); Thu, 26 Jan 2017 06:14:13 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,288,1477983600"; d="scan'208";a="57450777" Date: Thu, 26 Jan 2017 13:14:03 +0200 From: Jarkko Sakkinen To: Jason Gunthorpe Cc: tpmdd-devel@lists.sourceforge.net, linux-security-module@vger.kernel.org, Peter Huewe , Marcel Selhorst , open list Subject: Re: [PATCH RFC] tpm: define a command filter Message-ID: <20170126111403.ql6np2qulifxxw3p@intel.com> References: <20170124000258.16818-1-jarkko.sakkinen@linux.intel.com> <20170124001918.GA29735@obsidianresearch.com> <20170124143600.siyhblj67qaatewi@intel.com> <20170124190707.GA9899@obsidianresearch.com> <20170125202137.7bsv7lptvpzl2fjz@intel.com> <20170125221136.GA713@obsidianresearch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170125221136.GA713@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 Wed, Jan 25, 2017 at 03:11:36PM -0700, Jason Gunthorpe wrote: > On Wed, Jan 25, 2017 at 10:21:37PM +0200, Jarkko Sakkinen wrote: > > > There should be anyway someway to limit what commands can be sent but > > I understand your point. > > What is the filter for? > > James and I talked about a filter to create a safer cdev for use by > users. However tpms0 cannot be that 'safer' cdev - it is now the 'all > access' path. What do you mean by "safer cdev"? > I also suggested a filter in the kernel to ensure that the RM is only > passing commands it actually knows it handles properly. eg you would > filter out list handles. That is hardwired into the kernel, and does > not ge to be configured by user space. In many cases you would want to limit the set of operations that client can use. For example, not every client needs NV operations. In general you might want to have mechanism for limiting privileges. I haven't really considered this from the perspective that you've been discussing but more from the "principle of least privilege" perspective. Are you suggesting that in such cases you could just create daemon for proxying the traffic (when you want to limit privileges)? You could just make that daemon a whole lot simpler if it just needs to pass the file desriptor to the client after defining the set of operations that the client can use. This is a high priority decision to make because it's hard to apply principle of least privilege (with everything disallowed defaultts) if it is not done in the first place. /Jarkko