AW: [TrouSerS-tech] [tpmdd-devel] [PATCH 09/13] tpm: Pull everything related to sysfs into tpm-sysfs.c
Hi Jason, the Unix-Domain-Socket or DBus has actually been on my agenda for quite some time now, as soon as I find some time or MScCS student for it. If you know any... ;-) In any case, I like your idea to split trousers IPC to two distinct unix sockets for localities. In this case, we could also split tcsd into two processes along with it for accessing the distinct char-devices and thereby make it more robust against bugs for "locality-escalation". Also remember that many people have developed alternative stacks that don't use trousers but operate directly on the char-device. They would also benefit from char-device access control for localities. Even with only a single trousers, I see no harm in two devices. For backwards compatibility, the current /dev/tpm0 could be exported (with highest level access control) along with tpm0l1, tpm0l2, ... and/or trousers could open both char-devices if it wanted to. One more usecase for localities inside the kernel: The kernel may want to use localityAtRelease OS in order to protect sealed data (trusted keyrings) such that user-space could not even unseal those if they got the blob and the auth-secret; user-space malware. Without cap_compromise_kernel not even root could gain access in those cases... (I honestly don't know, if current trusted keyring incorporate localityAtRelease already, so never mind if I am just proposing implemented features) Cheers, Andreas Von: Jason Gunthorpe [jguntho...@obsidianresearch.com] Gesendet: Mittwoch, 9. Oktober 2013 19:38 On Tue, Oct 08, 2013 at 09:15:55AM +, Fuchs, Andreas wrote: > Rather than an ioctl, why not provide a different tpm-device per > locality. This way, the access to the different localities can be > restricted via standard user/group of the device. i.e. /dev/tpm0l1, > /dev/tpm0l2, ... or similar approaches... The way the TPM architecture is setup you will need the middle ware to do the switching between localities and managing cross locality resources, so it doesn't make sense for the kernel to export a locality specific char device. You'd have to do the above by having trousers create unix domain sockets for each of the privilege levels and using the usual security mechanisms to protect access to those sockets. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
AW: [TrouSerS-tech] [tpmdd-devel] [PATCH 09/13] tpm: Pull everything related to sysfs into tpm-sysfs.c
Hi Jason, the Unix-Domain-Socket or DBus has actually been on my agenda for quite some time now, as soon as I find some time or MScCS student for it. If you know any... ;-) In any case, I like your idea to split trousers IPC to two distinct unix sockets for localities. In this case, we could also split tcsd into two processes along with it for accessing the distinct char-devices and thereby make it more robust against bugs for locality-escalation. Also remember that many people have developed alternative stacks that don't use trousers but operate directly on the char-device. They would also benefit from char-device access control for localities. Even with only a single trousers, I see no harm in two devices. For backwards compatibility, the current /dev/tpm0 could be exported (with highest level access control) along with tpm0l1, tpm0l2, ... and/or trousers could open both char-devices if it wanted to. One more usecase for localities inside the kernel: The kernel may want to use localityAtRelease OS in order to protect sealed data (trusted keyrings) such that user-space could not even unseal those if they got the blob and the auth-secret; user-space malware. Without cap_compromise_kernel not even root could gain access in those cases... (I honestly don't know, if current trusted keyring incorporate localityAtRelease already, so never mind if I am just proposing implemented features) Cheers, Andreas Von: Jason Gunthorpe [jguntho...@obsidianresearch.com] Gesendet: Mittwoch, 9. Oktober 2013 19:38 On Tue, Oct 08, 2013 at 09:15:55AM +, Fuchs, Andreas wrote: Rather than an ioctl, why not provide a different tpm-device per locality. This way, the access to the different localities can be restricted via standard user/group of the device. i.e. /dev/tpm0l1, /dev/tpm0l2, ... or similar approaches... The way the TPM architecture is setup you will need the middle ware to do the switching between localities and managing cross locality resources, so it doesn't make sense for the kernel to export a locality specific char device. You'd have to do the above by having trousers create unix domain sockets for each of the privilege levels and using the usual security mechanisms to protect access to those sockets. Jason -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
AW: [TrouSerS-tech] [tpmdd-devel] [PATCH 09/13] tpm: Pull everything related to sysfs into tpm-sysfs.c
Some thoughts on those two questions: 1. Yes, userspace could be interested in setting TPM Localities specifically for uses of PCR_Reset. For example a Browser could be interested in scheduling Tabs in a PCR. For this it would reset the PCR and replay the old Extends when switching a tab. Then the Tab could continue Extending on those pcrs. Use cases may include any user-application that schedules children's tpm-access via PCR_Reset... The problem is, that whilst one process may be allowed to do so, another one may not. 2. This brings us to the problem of differentiating processes' access-rights on the locality-feature and more specifically how to move this through the tcsd (as another layer of abstraction). From a tpmdd perspective, if you provide localities, you will not want to allow for everyone to just randomly set them. They actually correspond to "capabilities" or access-rights on the TPM... Random Proposal for discussion: Rather than an ioctl, why not provide a different tpm-device per locality. This way, the access to the different localities can be restricted via standard user/group of the device. i.e. /dev/tpm0l1, /dev/tpm0l2, ... or similar approaches... A privileged application may access /dev/tpm0l2 whilst another one only gets to l1... Just some random thoughts, not well thought through though... ;-) Cheers, Andreas Von: Jason Gunthorpe [jguntho...@obsidianresearch.com] Gesendet: Freitag, 4. Oktober 2013 19:08 An: Joel Schopp Cc: Leonidas Da Silva Barbosa; linux-kernel@vger.kernel.org; Rajiv Andrade; tpmdd-de...@lists.sourceforge.net; Richard Maciel Costa; trousers-t...@lists.sourceforge.net; Daniel De Graaf; Sirrix AG Betreff: Re: [TrouSerS-tech] [tpmdd-devel] [PATCH 09/13] tpm: Pull everything related to sysfs into tpm-sysfs.c On Mon, Sep 30, 2013 at 05:09:51PM -0500, Joel Schopp wrote: > > So far, nobody I have talked to has offered any strong opinions on > > what locality should be used or how it should be set. I think finding > > a developer of trousers may be the most useful to talk about how the > > ioctl portion of this would need to be set up - if someone is actually > > needed. > I am a TrouSerS developer and am ccing Richard, another TrouSerS > developer, and ccing the trousers-tech list. It would be good if you > could elaborate on the question and context for those not following the > entire thread, myself included. Two questions: Is userspace interested in using the TPM Locality feature, and if so is there any thoughts on what the interface should be? Is the kernel interested in using the TPM Locality feature? What for? Jason -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791=/4140/ostg.clktrk ___ TrouSerS-tech mailing list trousers-t...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/trousers-tech -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
AW: [TrouSerS-tech] [tpmdd-devel] [PATCH 09/13] tpm: Pull everything related to sysfs into tpm-sysfs.c
Some thoughts on those two questions: 1. Yes, userspace could be interested in setting TPM Localities specifically for uses of PCR_Reset. For example a Browser could be interested in scheduling Tabs in a PCR. For this it would reset the PCR and replay the old Extends when switching a tab. Then the Tab could continue Extending on those pcrs. Use cases may include any user-application that schedules children's tpm-access via PCR_Reset... The problem is, that whilst one process may be allowed to do so, another one may not. 2. This brings us to the problem of differentiating processes' access-rights on the locality-feature and more specifically how to move this through the tcsd (as another layer of abstraction). From a tpmdd perspective, if you provide localities, you will not want to allow for everyone to just randomly set them. They actually correspond to capabilities or access-rights on the TPM... Random Proposal for discussion: Rather than an ioctl, why not provide a different tpm-device per locality. This way, the access to the different localities can be restricted via standard user/group of the device. i.e. /dev/tpm0l1, /dev/tpm0l2, ... or similar approaches... A privileged application may access /dev/tpm0l2 whilst another one only gets to l1... Just some random thoughts, not well thought through though... ;-) Cheers, Andreas Von: Jason Gunthorpe [jguntho...@obsidianresearch.com] Gesendet: Freitag, 4. Oktober 2013 19:08 An: Joel Schopp Cc: Leonidas Da Silva Barbosa; linux-kernel@vger.kernel.org; Rajiv Andrade; tpmdd-de...@lists.sourceforge.net; Richard Maciel Costa; trousers-t...@lists.sourceforge.net; Daniel De Graaf; Sirrix AG Betreff: Re: [TrouSerS-tech] [tpmdd-devel] [PATCH 09/13] tpm: Pull everything related to sysfs into tpm-sysfs.c On Mon, Sep 30, 2013 at 05:09:51PM -0500, Joel Schopp wrote: So far, nobody I have talked to has offered any strong opinions on what locality should be used or how it should be set. I think finding a developer of trousers may be the most useful to talk about how the ioctl portion of this would need to be set up - if someone is actually needed. I am a TrouSerS developer and am ccing Richard, another TrouSerS developer, and ccing the trousers-tech list. It would be good if you could elaborate on the question and context for those not following the entire thread, myself included. Two questions: Is userspace interested in using the TPM Locality feature, and if so is there any thoughts on what the interface should be? Is the kernel interested in using the TPM Locality feature? What for? Jason -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ TrouSerS-tech mailing list trousers-t...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/trousers-tech -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
