From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> To: James Bottomley <James.Bottomley@HansenPartnership.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>, Andy Lutomirski <luto@kernel.org> Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager Date: Wed, 4 Jan 2017 11:31:25 -0700 [thread overview] Message-ID: <20170104183125.GC783@obsidianresearch.com> (raw) In-Reply-To: <1483541583.2561.20.camel@HansenPartnership.com> 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. > 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. No messing with udev, no opt-in to TPM usage, no daemon to install, no chmod on a dev node. It Just Works. > Now if we look at use cases, for my laptop, where I'm the only user, I > want unrestricted access to the TPM. I can achieve that by making > /dev/tpms0 0666 (or changing its ownership to me). This usecase is already handled by making /dev/tmp0 accessible to the user. Keeping the 'enable RM' ioctl makes that a little wonky but entirely workable.. > Jason's use case is devices running non-root apps that need restricted > TPM access. For them, a single filter on /dev/tpms0 might work, > although there might be unrestricted apps needing a broader range of > tpm access (perhaps not all running as root?) Yes, I have a range of usage restrictions. As an example: My systems support key migration, so I want to make it very hard for an attacker to use the migration machinery to steal an RSA key. The user controls the migration password, I hope it is strong, but even so the system is currently desgined so that only a ssh user can even issue migration commands to the tpm. Someone hacking a network daemon simply cannot. This is the sort of defence in depth I think is imporant in a security system like this. > For the cloud use case, we're going to have a variety of applications > each with a variety of restrictions (for instance, the orchestration > system is definitely going to need PCR extensions if it's doing > attestations, but the guests might not want this) etc. To me a design for how the PCRs actually need to work is what is missing here. I only minimially understand this use case... And it seems like a big leap that orchestration software *needs* unprivileged TPM access. > I think all this points to multiple potential users each with their own > filter, so I think the actual architecture for the filter is an ioctl > which adds a new filtered device connected to the RM which may be > executed many times. Maybe, but that also seems like over kill.. It entirely depends on what the PCR use model actually is. Here is an alternative starting idea: - Introduce /dev/tpms a single cdev node that can talk to all chips and all localities. - By default it is 0666 - By default it has a very strong filter allowing only key load, some key ops and any thing else we can identify as unambiguously safe. - It has a root-only ioctl that can change the filter (op, chip) - It has a root-only ioctl that can change the locality - Keep the enable-RM ioctl on /dev/tmpX, except that enable-RM would switch the /dev/tpm0 FD to only use the above uAPI and set an all-permissive filter. The followup would be a TPM namespace design that meets the needs of people working on containers and related. We already know we need this today for IMA in containers and vtpm isolation. TPM namespaces would basically control the filtering options on /dev/tmps and set the default TPM. So one could run orchestration software unprivileged inside a TPM namespace with greater access. This should be enough stuff for people to explore different security models in user space. The root-only ioctls and /dev/tpm0 are enough to let user space create FDs with whatever properties are needed and pass them to unprivileged, eg via fd passing or via open-as-root/drop privs techniques. The default configuration is enough to enable the RSA key model that we actually do understand well and almost have code for :) I think this is very important.. We don't introduce any new security risks we don't understand. Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> To: James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> Cc: linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, open list <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> Subject: Re: [PATCH RFC 0/4] RFC: in-kernel resource manager Date: Wed, 4 Jan 2017 11:31:25 -0700 [thread overview] Message-ID: <20170104183125.GC783@obsidianresearch.com> (raw) In-Reply-To: <1483541583.2561.20.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> 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. > 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. No messing with udev, no opt-in to TPM usage, no daemon to install, no chmod on a dev node. It Just Works. > Now if we look at use cases, for my laptop, where I'm the only user, I > want unrestricted access to the TPM. I can achieve that by making > /dev/tpms0 0666 (or changing its ownership to me). This usecase is already handled by making /dev/tmp0 accessible to the user. Keeping the 'enable RM' ioctl makes that a little wonky but entirely workable.. > Jason's use case is devices running non-root apps that need restricted > TPM access. For them, a single filter on /dev/tpms0 might work, > although there might be unrestricted apps needing a broader range of > tpm access (perhaps not all running as root?) Yes, I have a range of usage restrictions. As an example: My systems support key migration, so I want to make it very hard for an attacker to use the migration machinery to steal an RSA key. The user controls the migration password, I hope it is strong, but even so the system is currently desgined so that only a ssh user can even issue migration commands to the tpm. Someone hacking a network daemon simply cannot. This is the sort of defence in depth I think is imporant in a security system like this. > For the cloud use case, we're going to have a variety of applications > each with a variety of restrictions (for instance, the orchestration > system is definitely going to need PCR extensions if it's doing > attestations, but the guests might not want this) etc. To me a design for how the PCRs actually need to work is what is missing here. I only minimially understand this use case... And it seems like a big leap that orchestration software *needs* unprivileged TPM access. > I think all this points to multiple potential users each with their own > filter, so I think the actual architecture for the filter is an ioctl > which adds a new filtered device connected to the RM which may be > executed many times. Maybe, but that also seems like over kill.. It entirely depends on what the PCR use model actually is. Here is an alternative starting idea: - Introduce /dev/tpms a single cdev node that can talk to all chips and all localities. - By default it is 0666 - By default it has a very strong filter allowing only key load, some key ops and any thing else we can identify as unambiguously safe. - It has a root-only ioctl that can change the filter (op, chip) - It has a root-only ioctl that can change the locality - Keep the enable-RM ioctl on /dev/tmpX, except that enable-RM would switch the /dev/tpm0 FD to only use the above uAPI and set an all-permissive filter. The followup would be a TPM namespace design that meets the needs of people working on containers and related. We already know we need this today for IMA in containers and vtpm isolation. TPM namespaces would basically control the filtering options on /dev/tmps and set the default TPM. So one could run orchestration software unprivileged inside a TPM namespace with greater access. This should be enough stuff for people to explore different security models in user space. The root-only ioctls and /dev/tpm0 are enough to let user space create FDs with whatever properties are needed and pass them to unprivileged, eg via fd passing or via open-as-root/drop privs techniques. The default configuration is enough to enable the RSA key model that we actually do understand well and almost have code for :) I think this is very important.. We don't introduce any new security risks we don't understand. Jason ------------------------------------------------------------------------------ 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 19:23 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 ` Jason Gunthorpe [this message] 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=20170104183125.GC783@obsidianresearch.com \ --to=jgunthorpe@obsidianresearch.com \ --cc=James.Bottomley@HansenPartnership.com \ --cc=jarkko.sakkinen@linux.intel.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: 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.