From: James Bottomley <James.Bottomley@HansenPartnership.com> To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>, Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Cc: 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, 04 Jan 2017 06:53:03 -0800 [thread overview] Message-ID: <1483541583.2561.20.camel@HansenPartnership.com> (raw) In-Reply-To: <20170104125045.7lorpe55drnrqce5@intel.com> On Wed, 2017-01-04 at 14:50 +0200, Jarkko Sakkinen wrote: > On Tue, Jan 03, 2017 at 05:17:32PM -0700, Jason Gunthorpe wrote: > > On Tue, Jan 03, 2017 at 02:39:58PM -0800, James Bottomley wrote: [...] > > > > 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. > > > > Well, I also think trousers is wrong to do that. :) > > > > 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. I realise you want better than this, and I definitely think this is a worthy goal, but the point I want to make is that an 0666 device and trousers are basically equivalent. > > This is why I want to see a command white list in Jarkko's patches > > to start. Every command exposed needs a very careful security > > analysis first, and we should start with only the commands we know > > are safe :\ > > > > > > 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. > > > > Good point, yes, localities should be thought about when designing > > this new RM char dev uAPI... > > > > Our support for localities in the kernel today uses some really > > gross sysfs file and is basically insane, IMHO. > > > > Maybe there should be a /dev/tpmrm for each locality? If so then > > only the safe one with unwritable localities can be 0666 by > > default.. > > Do you see that it would be possible to have ioctl for setting the > locality, or is it out of the question? I'm planning to have an ioctl > for the whitelist anyway. 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. If we have an ioctl, we then have to introduce a "who's allowed to do this?" policy in the kernel. 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. I think we go with this now and do the filter later. On the filter design: 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). 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?) 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. 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. That way the creator of the device can decide the filter policy and the use policy via the standard device UNIX ACL and you can have lots of them to make this fine grained. It could also be done with something /dev/ptmx like, so perhaps a filesystem may be the answer as well? If you want, I can commit to building this once we have all the requirements and we can get Jarkko's patch set reviewed now without it. James
WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> To: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>, 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 06:53:03 -0800 [thread overview] Message-ID: <1483541583.2561.20.camel@HansenPartnership.com> (raw) In-Reply-To: <20170104125045.7lorpe55drnrqce5-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> On Wed, 2017-01-04 at 14:50 +0200, Jarkko Sakkinen wrote: > On Tue, Jan 03, 2017 at 05:17:32PM -0700, Jason Gunthorpe wrote: > > On Tue, Jan 03, 2017 at 02:39:58PM -0800, James Bottomley wrote: [...] > > > > 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. > > > > Well, I also think trousers is wrong to do that. :) > > > > 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. I realise you want better than this, and I definitely think this is a worthy goal, but the point I want to make is that an 0666 device and trousers are basically equivalent. > > This is why I want to see a command white list in Jarkko's patches > > to start. Every command exposed needs a very careful security > > analysis first, and we should start with only the commands we know > > are safe :\ > > > > > > 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. > > > > Good point, yes, localities should be thought about when designing > > this new RM char dev uAPI... > > > > Our support for localities in the kernel today uses some really > > gross sysfs file and is basically insane, IMHO. > > > > Maybe there should be a /dev/tpmrm for each locality? If so then > > only the safe one with unwritable localities can be 0666 by > > default.. > > Do you see that it would be possible to have ioctl for setting the > locality, or is it out of the question? I'm planning to have an ioctl > for the whitelist anyway. 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. If we have an ioctl, we then have to introduce a "who's allowed to do this?" policy in the kernel. 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. I think we go with this now and do the filter later. On the filter design: 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). 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?) 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. 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. That way the creator of the device can decide the filter policy and the use policy via the standard device UNIX ACL and you can have lots of them to make this fine grained. It could also be done with something /dev/ptmx like, so perhaps a filesystem may be the answer as well? If you want, I can commit to building this once we have all the requirements and we can get Jarkko's patch set reviewed now without it. 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 14:54 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 ` James Bottomley [this message] 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=1483541583.2561.20.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=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.