[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170105192025.GB12587@obsidianresearch.com>
Date: Thu, 5 Jan 2017 12:20:25 -0700
From: Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To: James Bottomley <jejb@...ux.vnet.ibm.com>
Cc: "Fuchs, Andreas" <andreas.fuchs@....fraunhofer.de>,
"linux-security-module@...r.kernel.org"
<linux-security-module@...r.kernel.org>,
"tpmdd-devel@...ts.sourceforge.net"
<tpmdd-devel@...ts.sourceforge.net>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager
On Thu, Jan 05, 2017 at 10:33:43AM -0800, James Bottomley wrote:
> > A combo ioctl that could setup the session, issue an operation in it
> > and then delete the session, for instance.
>
> This would work for encryption or HMAC sessions, but probably not for
> policy sessions, because they can have an arbitrarily large command
> sequence to construct them.
I'd rather give up features (eg policy sessions, if necessary) for the
unpriv fd than give up security of the unpriv fd.
We always have the out that special stuff can go down the priv path.
> The other issue we're likely to run into if we do it this way is
> delayed error reporting.
Not sure I follow.
> How about a more traditional approach which would be leasing (basically
> what we use for NFS). Any application opening a session would have
Doesn't this just change the DOS vector? Now the attacker has to delay
execution of TPM commands long enough to force session leases to time
out. That isn't too hard to do, asking the TPM to make a RSA key can
take seconds, for instance.
Jason
Powered by blists - more mailing lists