From: James Bottomley <James.Bottomley@HansenPartnership.com> To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>, linux-security-module@vger.kernel.org, tpmdd-devel@lists.sourceforge.net, open list <linux-kernel@vger.kernel.org> Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager Date: Tue, 03 Jan 2017 14:39:58 -0800 [thread overview] Message-ID: <1483483198.2464.44.camel@HansenPartnership.com> (raw) In-Reply-To: <20170103214702.GC29656@obsidianresearch.com> On Tue, 2017-01-03 at 14:47 -0700, Jason Gunthorpe wrote: > On Tue, Jan 03, 2017 at 08:36:10AM -0800, James Bottomley wrote: > > > > I'm not sure about this. Why you couldn't have a very thin daemon > > > that prepares the file descriptor and sends it through UDS socket > > > to a client. > > > > So I'm a bit soured on daemons from the trousers experience: tcsd > > crashed regularly and when it did it took all the TPM connections > > down irrecoverably. I'm not saying we can't write a stateless > > daemon to fix most of the trousers issues, but I think it's > > valuable first to ask the question, "can we manage without a daemon > > at all?" I actually think the answer is "yes", so I'm interested > > in seeing how far that line of research gets us. > > There is clearly no need for a daemon to be involved when working on > simple tasks like key load and key sign/enc/dec actions, adding such > a thing only increases the complexity. > > If we discover a reason to have a daemon down the road then it should > work in some way where the user space can call out to the daemon over > a different path than the kernel. (eg dbus or something) Agreed ... I think the only reason I can currently see for needing a daemon is if we need it to sort out access security (which I'm hoping we don't). > > Do you have a link to the presentation? The Plumbers etherpad > > doesn't contain it. I've been trying to work out whether a > > properly set up TPM actually does need any protections at all. As > > far as I can tell, once you've set all the hierarchy authorities > > and the lockout one, you're pretty well protected. > > I think we should also consider TPM 1.2 support in all of this, it is > still a very popular peice of hardware and it is equally able to > support a RM. I've been running with the openssl and gnome-keyring patches in 1.2 for months now. The thing about 1.2 is that the volatile store is much larger, so there's a lot less of a need for a RM. It's only a requirement in 2.0 because most shipping TPMs only seem to have room for about 3 objects. > So, in general, I'd prefer to see the unprivileged char dev hard > prevented by the kernel from doing certain things: > > - Wipe the TPM > - Manipulate the SRK, nvram, tpm flags, change passwords etc > - Read back the EK These are all things that the TPM itself is capable of enforcing a policy for. I think we should aim for correct setup of the TPM in the first place so it enforces the policy in a standard manner rather than having an artificial policy enforcement in the kernel. > - Write to PCRs The design of a TPM is mostly that it's up to user space to deal with this. Userspace can, of course, kill the TPM ability to quote and seal to PCRs by inappropriately extending them. However, there are a lot of responsible applications that want to use PCRs in userspace; for instance cloud boot and attestation. We don't really want to restrict their ability arbitrarily. > - etc. > > Even if TPM 2 has a stronger password based model, I still think the > kernel should hard prevent those sorts of actions even if the user > knows the TPM password. That would make us different from TPM1.2: there, if you know the owner authorisation, trousers will pretty much let you do anything. > Realistically people in less senstive environments will want to use > the well known TPM passwords and still have reasonable safety in > their unprivileged accounts. Can we not do most of this with localities? In theory locality 0 is supposed to be only the bios and the boot manager and the OS gets to access 1-3. We could reserve one for the internal kernel and still have a couple for userspace (I'll have to go back and check numbers; I seem to remember there were odd restrictions on which PCR you can reset and extend in which locality). If we have two devices (one for each locality) we could define a UNIX ACL on the devices to achieve what you want. 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> Subject: Re: [PATCH RFC 0/4] RFC: in-kernel resource manager Date: Tue, 03 Jan 2017 14:39:58 -0800 [thread overview] Message-ID: <1483483198.2464.44.camel@HansenPartnership.com> (raw) In-Reply-To: <20170103214702.GC29656-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> On Tue, 2017-01-03 at 14:47 -0700, Jason Gunthorpe wrote: > On Tue, Jan 03, 2017 at 08:36:10AM -0800, James Bottomley wrote: > > > > I'm not sure about this. Why you couldn't have a very thin daemon > > > that prepares the file descriptor and sends it through UDS socket > > > to a client. > > > > So I'm a bit soured on daemons from the trousers experience: tcsd > > crashed regularly and when it did it took all the TPM connections > > down irrecoverably. I'm not saying we can't write a stateless > > daemon to fix most of the trousers issues, but I think it's > > valuable first to ask the question, "can we manage without a daemon > > at all?" I actually think the answer is "yes", so I'm interested > > in seeing how far that line of research gets us. > > There is clearly no need for a daemon to be involved when working on > simple tasks like key load and key sign/enc/dec actions, adding such > a thing only increases the complexity. > > If we discover a reason to have a daemon down the road then it should > work in some way where the user space can call out to the daemon over > a different path than the kernel. (eg dbus or something) Agreed ... I think the only reason I can currently see for needing a daemon is if we need it to sort out access security (which I'm hoping we don't). > > Do you have a link to the presentation? The Plumbers etherpad > > doesn't contain it. I've been trying to work out whether a > > properly set up TPM actually does need any protections at all. As > > far as I can tell, once you've set all the hierarchy authorities > > and the lockout one, you're pretty well protected. > > I think we should also consider TPM 1.2 support in all of this, it is > still a very popular peice of hardware and it is equally able to > support a RM. I've been running with the openssl and gnome-keyring patches in 1.2 for months now. The thing about 1.2 is that the volatile store is much larger, so there's a lot less of a need for a RM. It's only a requirement in 2.0 because most shipping TPMs only seem to have room for about 3 objects. > So, in general, I'd prefer to see the unprivileged char dev hard > prevented by the kernel from doing certain things: > > - Wipe the TPM > - Manipulate the SRK, nvram, tpm flags, change passwords etc > - Read back the EK These are all things that the TPM itself is capable of enforcing a policy for. I think we should aim for correct setup of the TPM in the first place so it enforces the policy in a standard manner rather than having an artificial policy enforcement in the kernel. > - Write to PCRs The design of a TPM is mostly that it's up to user space to deal with this. Userspace can, of course, kill the TPM ability to quote and seal to PCRs by inappropriately extending them. However, there are a lot of responsible applications that want to use PCRs in userspace; for instance cloud boot and attestation. We don't really want to restrict their ability arbitrarily. > - etc. > > Even if TPM 2 has a stronger password based model, I still think the > kernel should hard prevent those sorts of actions even if the user > knows the TPM password. That would make us different from TPM1.2: there, if you know the owner authorisation, trousers will pretty much let you do anything. > Realistically people in less senstive environments will want to use > the well known TPM passwords and still have reasonable safety in > their unprivileged accounts. Can we not do most of this with localities? In theory locality 0 is supposed to be only the bios and the boot manager and the OS gets to access 1-3. We could reserve one for the internal kernel and still have a couple for userspace (I'll have to go back and check numbers; I seem to remember there were odd restrictions on which PCR you can reset and extend in which locality). If we have two devices (one for each locality) we could define a UNIX ACL on the devices to achieve what you want. 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-03 22:40 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 ` James Bottomley [this message] 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 ` [tpmdd-devel] " James Bottomley 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=1483483198.2464.44.camel@HansenPartnership.com \ --to=james.bottomley@hansenpartnership.com \ --cc=jarkko.sakkinen@linux.intel.com \ --cc=jgunthorpe@obsidianresearch.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.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: linkBe 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.