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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 10 Oct 2013 07:42:49 +0000
From:	"Fuchs, Andreas" <andreas.fuchs@....fraunhofer.de>
To:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
CC:	Joel Schopp <jschopp@...ux.vnet.ibm.com>,
	Leonidas Da Silva Barbosa <leosilva@...ux.vnet.ibm.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Rajiv Andrade <mail@...jiv.net>,
	"tpmdd-devel@...ts.sourceforge.net" 
	<tpmdd-devel@...ts.sourceforge.net>,
	Richard Maciel Costa <richardm@...ibm.com>,
	"trousers-tech@...ts.sourceforge.net" 
	<trousers-tech@...ts.sourceforge.net>,
	Daniel De Graaf <dgdegra@...ho.nsa.gov>,
	Sirrix AG <tpmdd@...rix.com>
Subject: 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 [jgunthorpe@...idianresearch.com]
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/