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]

Date:   Thu, 05 Jan 2017 14:58:46 -0800
From:   James Bottomley <jejb@...ux.vnet.ibm.com>
To:     Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Cc:     "tpmdd-devel@...ts.sourceforge.net" 
        <tpmdd-devel@...ts.sourceforge.net>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

On Thu, 2017-01-05 at 15:21 -0700, Jason Gunthorpe wrote:
> On Thu, Jan 05, 2017 at 11:55:49AM -0800, James Bottomley wrote:
> 
> > We don't really have that choice: Keys require authorization, so 
> > you have to have an auth session.
> 
> I know, this is why I suggested a combo op (kernel level atomicity
> is clearly DOS safe)..

Transactions are a hard thing to guarantee to be DoS safe and the more
complex they get, the more difficult they are to police within the
kernel.  Plus we have to keep the R/W interface for backwards
compatibility now that we have it and I just don't see how we could
layer transactions into it without having some sort of in-kernel
emulator.

> > If you want things like PCR sealed or time limited keys, you don't
> > really have a choice on policy sessions either.
> 
> .. and advanced stuff like is what I was talking about giving up for
> unpriv if it can't be allowed safely ...
> 
> > I think we've got to the point where arguing about our divergent 
> > use requirements shows the default should be 0600 and every command
> > enabled so that whatever changes the device to 0666 also applies 
> > the command
> 
> Well, that is what we already have with /dev/tpm0.

Except that doesn't have the RM.

> I'm very surprised by this level of disagreement, so I'm inclined to
> drop the idea that the kernel can directly support a 0666 cdev at
> all.

Great.  We'll keep it at 0600 and let userspace sort it out; that way
policy becomes flexible too.

> Lets stick with the user space broker process and just introduce
> enough kernel RM to enable co-existance with kernel users and clean
> -up on crash. This should be enough to make a user space broker much
> simpler.

I wouldn't go that far.  I'm still planning a userspace tss2 without
any access broker daemon, but let's see how far I get on top of the RM.
 I think building in stages is a good way to get actual use experience
to guide the next stage.

> So Jarkko's uapi is basically fine.. No need for a kernel white
> list/etc

I suspect we'll eventually get to needing one, but I'm happy to begin
without and see what that experience tells us before we try to build
it.  This is actually a better way of doing stuff because we can add to
an API based on what we find in the field; the hard thing is pulling
back an API that doesn't work.

> I had really hoped we could have a secure default 0666 cdev that
> would be able to support the basic use of your user space plugins
> without a daemon :(

I think we can; I just don't think we can define a single in-kernel use
policy that supports everyone's use case, so punting to userspace and
letting it sort out the desired policy for the platform will work for
everyone.

James