linux-kernel - Re: [PATCH RFC] tpm: define a command filter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170125221136.GA713@obsidianresearch.com>
Date:   Wed, 25 Jan 2017 15:11:36 -0700
From:   Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
Cc:     tpmdd-devel@...ts.sourceforge.net,
        linux-security-module@...r.kernel.org,
        Peter Huewe <peterhuewe@....de>,
        Marcel Selhorst <tpmdd@...horst.net>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC] tpm: define a command filter

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.

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.

> Would it make more sense to have a sysfs file for configuring the
> global filter that would get the data in the same format (list of
> 16-bit words)?

Probably not, then there is no way to escape the filter in userspace,
so some command just become impossible even for root. (And no,
something like tpm should not test CAP_ flags, that is putting
too much policy into the kernel)

Jason