From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: linux-security-module@vger.kernel.org,
tpmdd-devel@lists.sourceforge.net,
Andy Lutomirski <luto@kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager
Date: Wed, 04 Jan 2017 10:57:51 -0800 [thread overview]
Message-ID: <1483556271.2561.50.camel@HansenPartnership.com> (raw)
In-Reply-To: <20170104183125.GC783@obsidianresearch.com>
On Wed, 2017-01-04 at 11:31 -0700, Jason Gunthorpe wrote:
> On Wed, Jan 04, 2017 at 06:53:03AM -0800, James Bottomley wrote:
>
> > > > But this is not trousers, this is an in-kernel 0666 char dev
> > > > that will be active on basically every Linux system with a TPM.
> > > > I think we have a duty to be very conservative here.
> >
> > Just to note on this that trousers *is* effectively an 0666 kernel
> > device: all tcsd does is run with root privileges on the real
> > /dev/tpm0 and mediate the calls. It doesn't seem to police them at
> > all.
>
> That may be, but IHMO trousers is simply not relevant. Real systems
> do not seem to use trousers. I don't use it. Google doesn't use it.
> You report it is crashy.
>
> To me it just doesn't represent a reasonable way to use the TPM
> hardware.
It basically represents the only current way until there's a new API,
so all our current key handling tools use it. Given how I slammed it
in Plumbers, I'd be the last one to defend its actual API as usable ...
we just don't have another (yet).
> > For localities, assuming they can have real meaning in terms of the
> > protection model, I think one device per locality is better than an
> > ioctl because device policy is settable in underspace via the UNIX
> > ACL and hence locality policy is too.
>
> Yes.
>
> > I also think the command filter actually needs more thought. Right
> > at the moment, if we go with the current proposals, the kernel will
> > create two devices: /dev/tpm<n> and /dev/tpms<n>. By default
> > they'll both be root owned and 0600, so the current patch
> > adequately protects the TPM.
>
> Yes, but, considering the goals here I'd rather see the default
> kernel permissions for tpms be 0666 ....
>
> You are doing all this work to get the user space side in shape, I'd
> like to see matching kernel support. To me that means out-of-the-box
> a user can just use your plugins, the plugins will access /dev/tmps
> and everything will work fine for RSA key storage.
Actually, not necessarily; you're not considering the setup issue:
right at the moment users get delivered TPMs mostly in the cleared
state (thankfully they no longer have to clear via bios). So the first
thing a new user has to do is set all the authorizations and create an
SRK equivalent primary object at 0x81000001. I think in the interests
of best practice we want to make that as easy as possible; saying they
have to do this as root and use a different device is problematic.
You can say they don't have to use a different device because the
filter can be lifted for root, but then how do I lock down root apps
for this untrusted root setup secure boot has going on?
I suppose we could use TPMA_PERMANENT for this. The first three bits
indicate whether the authorizations are set, so if they're all clear,
we can assume an unowned TPM and lift the filter? A sort of trust on
first use model.
James
WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
To: Jason Gunthorpe
<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Cc: linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
open, list <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Subject: Re: [PATCH RFC 0/4] RFC: in-kernel resource manager
Date: Wed, 04 Jan 2017 10:57:51 -0800 [thread overview]
Message-ID: <1483556271.2561.50.camel@HansenPartnership.com> (raw)
In-Reply-To: <20170104183125.GC783-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On Wed, 2017-01-04 at 11:31 -0700, Jason Gunthorpe wrote:
> On Wed, Jan 04, 2017 at 06:53:03AM -0800, James Bottomley wrote:
>
> > > > But this is not trousers, this is an in-kernel 0666 char dev
> > > > that will be active on basically every Linux system with a TPM.
> > > > I think we have a duty to be very conservative here.
> >
> > Just to note on this that trousers *is* effectively an 0666 kernel
> > device: all tcsd does is run with root privileges on the real
> > /dev/tpm0 and mediate the calls. It doesn't seem to police them at
> > all.
>
> That may be, but IHMO trousers is simply not relevant. Real systems
> do not seem to use trousers. I don't use it. Google doesn't use it.
> You report it is crashy.
>
> To me it just doesn't represent a reasonable way to use the TPM
> hardware.
It basically represents the only current way until there's a new API,
so all our current key handling tools use it. Given how I slammed it
in Plumbers, I'd be the last one to defend its actual API as usable ...
we just don't have another (yet).
> > For localities, assuming they can have real meaning in terms of the
> > protection model, I think one device per locality is better than an
> > ioctl because device policy is settable in underspace via the UNIX
> > ACL and hence locality policy is too.
>
> Yes.
>
> > I also think the command filter actually needs more thought. Right
> > at the moment, if we go with the current proposals, the kernel will
> > create two devices: /dev/tpm<n> and /dev/tpms<n>. By default
> > they'll both be root owned and 0600, so the current patch
> > adequately protects the TPM.
>
> Yes, but, considering the goals here I'd rather see the default
> kernel permissions for tpms be 0666 ....
>
> You are doing all this work to get the user space side in shape, I'd
> like to see matching kernel support. To me that means out-of-the-box
> a user can just use your plugins, the plugins will access /dev/tmps
> and everything will work fine for RSA key storage.
Actually, not necessarily; you're not considering the setup issue:
right at the moment users get delivered TPMs mostly in the cleared
state (thankfully they no longer have to clear via bios). So the first
thing a new user has to do is set all the authorizations and create an
SRK equivalent primary object at 0x81000001. I think in the interests
of best practice we want to make that as easy as possible; saying they
have to do this as root and use a different device is problematic.
You can say they don't have to use a different device because the
filter can be lifted for root, but then how do I lock down root apps
for this untrusted root setup secure boot has going on?
I suppose we could use TPMA_PERMANENT for this. The first three bits
indicate whether the authorizations are set, so if they're all clear,
we can assume an unowned TPM and lift the filter? A sort of trust on
first use model.
James
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
next prev parent reply other threads:[~2017-01-04 18:58 UTC|newest]
Thread overview: 150+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-02 13:22 [PATCH RFC 0/4] RFC: in-kernel resource manager Jarkko Sakkinen
2017-01-02 13:22 ` Jarkko Sakkinen
2017-01-02 13:22 ` [PATCH RFC 1/4] tpm: migrate struct tpm_buf to struct tpm_chip Jarkko Sakkinen
2017-01-02 13:22 ` Jarkko Sakkinen
2017-01-02 21:01 ` Jason Gunthorpe
2017-01-02 21:01 ` Jason Gunthorpe
2017-01-03 0:57 ` Jarkko Sakkinen
2017-01-03 19:13 ` Jason Gunthorpe
2017-01-03 19:13 ` Jason Gunthorpe
2017-01-04 12:29 ` Jarkko Sakkinen
2017-01-04 12:29 ` Jarkko Sakkinen
2017-01-02 13:22 ` [PATCH RFC 2/4] tpm: validate TPM 2.0 commands Jarkko Sakkinen
2017-01-02 13:22 ` Jarkko Sakkinen
[not found] ` <20170102132213.22880-3-jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-01-04 18:04 ` Stefan Berger
2017-01-04 18:19 ` [tpmdd-devel] " James Bottomley
2017-01-04 18:19 ` James Bottomley
[not found] ` <1483553976.2561.38.camel-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-01-04 18:59 ` Stefan Berger
[not found] ` <OF3FD1DF4F.FB87C3F2-ON0025809E.00682E9B-8525809E.00684A8A-8eTO7WVQ4XIsd+ienQ86orlN3bxYEBpz@public.gmane.org>
2017-01-04 19:05 ` James Bottomley
[not found] ` <1483556735.2561.53.camel-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-01-04 19:22 ` Stefan Berger
[not found] ` <OFDFABBD23.E5E1F639-ON0025809E.006924C4-8525809E.006A7568-8eTO7WVQ4XIsd+ienQ86orlN3bxYEBpz@public.gmane.org>
2017-01-09 22:17 ` Jarkko Sakkinen
[not found] ` <20170109221700.q7tq362rd6r23d5b-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-01-09 22:39 ` Stefan Berger
2017-01-04 18:44 ` [tpmdd-devel] " Jason Gunthorpe
2017-01-04 18:44 ` Jason Gunthorpe
2017-01-02 13:22 ` [PATCH RFC 3/4] tpm: export tpm2_flush_context_cmd Jarkko Sakkinen
2017-01-02 13:22 ` Jarkko Sakkinen
2017-01-02 13:22 ` [PATCH RFC 4/4] tpm: add the infrastructure for TPM space for TPM 2.0 Jarkko Sakkinen
2017-01-02 13:22 ` Jarkko Sakkinen
2017-01-02 21:09 ` Jason Gunthorpe
2017-01-02 21:09 ` Jason Gunthorpe
2017-01-03 0:37 ` Jarkko Sakkinen
2017-01-03 18:46 ` Jason Gunthorpe
2017-01-03 18:46 ` Jason Gunthorpe
2017-01-04 12:43 ` Jarkko Sakkinen
2017-01-04 12:43 ` Jarkko Sakkinen
2017-01-03 19:16 ` Jason Gunthorpe
2017-01-03 19:16 ` Jason Gunthorpe
2017-01-04 12:45 ` Jarkko Sakkinen
2017-01-04 12:45 ` Jarkko Sakkinen
[not found] ` <20170102132213.22880-5-jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-01-04 17:50 ` Stefan Berger
2017-01-09 22:11 ` [tpmdd-devel] " Jarkko Sakkinen
2017-01-02 16:36 ` [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager James Bottomley
2017-01-02 19:33 ` Jarkko Sakkinen
2017-01-02 19:33 ` Jarkko Sakkinen
2017-01-02 21:40 ` [tpmdd-devel] " James Bottomley
2017-01-02 21:40 ` James Bottomley
2017-01-03 5:26 ` [tpmdd-devel] " James Bottomley
2017-01-03 13:41 ` Jarkko Sakkinen
2017-01-03 13:41 ` Jarkko Sakkinen
2017-01-03 16:14 ` [tpmdd-devel] " James Bottomley
2017-01-03 16:14 ` James Bottomley
2017-01-03 18:36 ` [tpmdd-devel] " Jarkko Sakkinen
2017-01-03 18:36 ` Jarkko Sakkinen
2017-01-03 19:14 ` [tpmdd-devel] " Jarkko Sakkinen
2017-01-03 19:14 ` Jarkko Sakkinen
2017-01-03 19:34 ` [tpmdd-devel] " James Bottomley
2017-01-03 19:34 ` James Bottomley
2017-01-03 21:54 ` [tpmdd-devel] " Jason Gunthorpe
2017-01-03 21:54 ` Jason Gunthorpe
2017-01-04 12:58 ` [tpmdd-devel] " Jarkko Sakkinen
2017-01-04 12:58 ` Jarkko Sakkinen
2017-01-04 16:55 ` [tpmdd-devel] " Jason Gunthorpe
2017-01-04 16:55 ` Jason Gunthorpe
2017-01-04 5:47 ` [tpmdd-devel] " Andy Lutomirski
2017-01-04 13:00 ` Jarkko Sakkinen
2017-01-03 13:51 ` Jarkko Sakkinen
2017-01-03 13:51 ` Jarkko Sakkinen
2017-01-03 16:36 ` [tpmdd-devel] " James Bottomley
2017-01-03 16:36 ` James Bottomley
2017-01-03 18:40 ` [tpmdd-devel] " Jarkko Sakkinen
2017-01-03 21:47 ` Jason Gunthorpe
2017-01-03 22:21 ` Ken Goldman
2017-01-03 22:21 ` Ken Goldman
2017-01-03 23:20 ` [tpmdd-devel] " Jason Gunthorpe
2017-01-03 23:20 ` Jason Gunthorpe
[not found] ` <20170103214702.GC29656-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2017-01-03 22:22 ` Ken Goldman
2017-01-03 22:39 ` [tpmdd-devel] " James Bottomley
2017-01-03 22:39 ` James Bottomley
2017-01-04 0:17 ` [tpmdd-devel] " Jason Gunthorpe
2017-01-04 0:29 ` James Bottomley
2017-01-04 0:29 ` James Bottomley
2017-01-04 0:56 ` [tpmdd-devel] " Jason Gunthorpe
2017-01-04 0:56 ` Jason Gunthorpe
2017-01-04 12:50 ` [tpmdd-devel] " Jarkko Sakkinen
2017-01-04 12:50 ` Jarkko Sakkinen
2017-01-04 14:53 ` [tpmdd-devel] " James Bottomley
2017-01-04 14:53 ` James Bottomley
2017-01-04 18:31 ` [tpmdd-devel] " Jason Gunthorpe
2017-01-04 18:31 ` Jason Gunthorpe
2017-01-04 18:57 ` James Bottomley [this message]
2017-01-04 18:57 ` James Bottomley
2017-01-04 19:24 ` [tpmdd-devel] " Jason Gunthorpe
2017-01-04 19:24 ` Jason Gunthorpe
[not found] ` <20170104001732.GB32185-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2017-01-10 18:55 ` Ken Goldman
2017-01-04 12:48 ` [tpmdd-devel] " Jarkko Sakkinen
2017-01-04 12:48 ` Jarkko Sakkinen
[not found] ` <1483461370.2464.19.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2017-01-03 22:18 ` Ken Goldman
2017-01-03 21:32 ` [tpmdd-devel] " Jason Gunthorpe
2017-01-03 21:32 ` Jason Gunthorpe
2017-01-03 22:03 ` [tpmdd-devel] " James Bottomley
2017-01-05 15:52 ` Fuchs, Andreas
2017-01-05 15:52 ` Fuchs, Andreas
2017-01-05 17:27 ` [tpmdd-devel] " Jason Gunthorpe
2017-01-05 17:27 ` Jason Gunthorpe
2017-01-05 18:06 ` [tpmdd-devel] " James Bottomley
2017-01-05 18:06 ` James Bottomley
2017-01-06 8:43 ` [tpmdd-devel] " Andreas Fuchs
2017-01-06 8:43 ` Andreas Fuchs
[not found] ` <410e3045-58dc-5415-30c1-c86eb916b6c8-iXjGqz/onsDSyEMIgutvibNAH6kLmebB@public.gmane.org>
2017-01-10 18:57 ` Ken Goldman
2017-01-05 18:33 ` [tpmdd-devel] " James Bottomley
2017-01-05 18:33 ` James Bottomley
2017-01-05 19:20 ` Jason Gunthorpe
2017-01-05 19:20 ` Jason Gunthorpe
2017-01-05 19:55 ` [tpmdd-devel] " James Bottomley
2017-01-05 19:55 ` James Bottomley
2017-01-05 22:21 ` Jason Gunthorpe
2017-01-05 22:21 ` Jason Gunthorpe
2017-01-05 22:58 ` [tpmdd-devel] " James Bottomley
2017-01-05 22:58 ` James Bottomley
2017-01-05 23:50 ` [tpmdd-devel] " Jason Gunthorpe
2017-01-05 23:50 ` Jason Gunthorpe
2017-01-06 0:36 ` [tpmdd-devel] " James Bottomley
2017-01-06 0:36 ` James Bottomley
2017-01-06 8:59 ` Andreas Fuchs
2017-01-06 8:59 ` Andreas Fuchs
2017-01-06 19:10 ` [tpmdd-devel] " Jason Gunthorpe
2017-01-06 19:10 ` Jason Gunthorpe
2017-01-06 19:02 ` [tpmdd-devel] " Jason Gunthorpe
2017-01-06 19:02 ` Jason Gunthorpe
2017-01-10 19:03 ` Ken Goldman
2017-01-10 19:03 ` Ken Goldman
2017-01-09 22:39 ` [tpmdd-devel] " Jarkko Sakkinen
2017-01-09 22:39 ` Jarkko Sakkinen
2017-01-11 10:03 ` Andreas Fuchs
2017-01-11 10:03 ` Andreas Fuchs
2017-01-04 16:12 Dr. Greg Wettstein
2017-01-04 16:12 ` Dr. Greg Wettstein
2017-01-09 23:16 ` Jarkko Sakkinen
2017-01-10 19:29 ` Ken Goldman
2017-01-10 19:29 ` Ken Goldman
2017-01-11 11:36 ` Jarkko Sakkinen
2017-01-10 20:05 ` Jason Gunthorpe
2017-01-11 10:00 ` Andreas Fuchs
2017-01-11 18:03 ` Jason Gunthorpe
2017-01-11 18:27 ` Stefan Berger
2017-01-11 19:18 ` Jason Gunthorpe
2017-01-11 11:34 ` Jarkko Sakkinen
2017-01-11 15:39 ` James Bottomley
2017-01-11 17:56 ` Jason Gunthorpe
2017-01-11 18:25 ` James Bottomley
2017-01-11 19:04 ` Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1483556271.2561.50.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=jgunthorpe@obsidianresearch.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@kernel.org \
--cc=tpmdd-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.