On 07/27/2017 03:39 PM, Magalhaes, Guilherme (Brazil R&D-CL) wrote:

quoted

There's a vTPM proxy driver in the kernel that enables spawning a
frontend /dev/tpm%d and an anonymous backend file descriptor where a
vTPM can listen on for TPM commands. I integrated this with 'swtpm' and
I have been working on integrating this into runc. Currently each
container started with runc can get one (or multiple) vTPMs and
/dev/tpm0 [and /dev/tpmrm0 in case of TPM2] then appear inside the
container.

This is an interesting solution especially for nested namespaces with the
recursive application of measurements and a having list per container.

Following the TCG specs/requirements, what could we say about security
guarantees of real TPMs Vs this vTPM implementation?

A non-root user may not be able to do access the (permanent) state of 
the vTPM state files since the container management stack would restrict 
access to the files using DAC. Access to runtime data is also prevented 
since the vTPM would not run under the account of the non-root user.

To protect the vTPM's permanent state file from access by a root user it 
comes down to preventing the root user from getting a hold of the key 
used for encrypting that file. Encrypting the state of the vTPM is 
probably the best we can do to approximate a temper-resistant chip, but 
preventing the root user from accessing the key may be more challenging.
Preventing root from accessing runtime data could be achieved by using 
XGS or a similar technology.

     Stefan


--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html