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

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: <1484159157.2509.23.camel@HansenPartnership.com>
Date:   Wed, 11 Jan 2017 10:25:57 -0800
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Cc:     Ken Goldman <kgoldman@...ibm.com>, greg@...ellic.com,
        linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        tpmdd-devel@...ts.sourceforge.net
Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

On Wed, 2017-01-11 at 10:56 -0700, Jason Gunthorpe wrote:
> On Wed, Jan 11, 2017 at 07:39:53AM -0800, James Bottomley wrote:
> 
> > RAW access means the ability to DoS the TPM simply by exhausting
> > handles.  Therefore, I think most applications only get RM access.
> 
> Re-read what Jarkko is proposing. He is not making a complete safe &
> secure RM in the kernel. He is making a tool to allow userspace and
> the kernel to share the TPM sanely.
> 
> It is not an access control tool, it is not a security tool, it is 
> not intended to support safe unpriv userspace access.
> 
> So there is no reason to have a different access control model in
> userspace, it is not a fundamentally different security environment
> from the existing raw device.
> 
> A future project to provide an unpriv safe cdev from the kernel is
> something different.

Right, but we're going around in circles.  I'm currently researching
what it would take to be daemonless, so an ioctl which requires an
access broker daemon would obviously be something I'd object to.

Basically, though, I think you can do both: we can add an ioctl and the
differing device hooks.  I just think for that case RAW vs RM would be
redundant.

James