AW: [TrouSerS-tech] [tpmdd-devel] [PATCH 09/13] tpm: Pulleverything related to sysfs into tpm-sysfs.c

[Fuchs, Andreas]

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 [jgunthorpe@xxxxxxxxxxxxxxxxxxxx]
Gesendet: Mittwoch, 9. Oktober 2013 19:38

On Tue, Oct 08, 2013 at 09:15:55AM +0000, 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/