lkml.org 
[lkml]   [2017]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH RFC] tpm: define a command filter
On Thu, Jan 26, 2017 at 11:05:06AM -0700, Jason Gunthorpe wrote:
> On Thu, Jan 26, 2017 at 01:14:03PM +0200, Jarkko Sakkinen wrote:
> > 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"?
>
> 'safer cdev' is this concept of limiting privileges you are describing
> below.
>
> > > 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.
>
> What does that mean? The kernel needs to provide an unrestricted
> access path to the TPM and the RM - typically for use by root. I don't
> think there is any debate on this point.
>
> The kernel *could* provide restricted access to the TPM and the RM -
> typically for use by a user.
>
> These are *different* things and they should not both exist at once on
> /dev/tpms0 (that is not the unix model).
>
> IMHO this patch series should focus entirely on the unrestricted
> access path. Otherwise the debate is too large and complex.

Agreed. We can add more granular access control later on.

For the rest of the response I understand your point of view but lets
continue after we have basic building blocks in place :-)

/Jarkko

\
 
 \ /
  Last update: 2017-01-27 07:48    [W:0.089 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site