Edward Pilatowicz wrote: > i have some concerns about the zones integration proposed by this case. > > in general, we recommend that applications be deployed within zones > since that provides an easy way to contain application configuration. > with this proposal, if an administrator deploys an application in a zone > which tries to use the TSS library, then they have to modify the > tcsd.conf file in the global zone. this breaks up the application > configuration across multiple zones and impacts zone migration, there by > eliminating the application encapsulation benefits that zones provides. > > this proposal also assumes that any zones which want to use the TSS > library functionality will have network access to the global zone. this > is an invalid assumption. exclusive ip stack zones allow for zones with > network configurations which are compleatly independent of the global > zone. depending on the deployment, the global zone may not even be > accessible via the network. > > i also don't see any discussion of security issues wrt allowing remote > access to the TSS daemon. once an admin decides to enable remote host > access via tcsd.conf, how is authentication and authorisation of remote > clients handled?
By default, network access is disabled. Authentication of sensitive commands is defined in the TSS specifications, the remote application would have to know the correct passphrases (which are encrypted) to be able to perform sensitive operations. The authentication and authorization is handled by the TCS Daemon according to the specifications and the settings in the tcsd.conf file. > looking at the tcsd.conf file, it seems that a zone administrator might > want to tune these configuration parameters locally within a zone > depending on the behaviour of the TSS library consumers running within > the zone. that's not possible with this proposal. This project is basically proposing to putback the current open source TSS stack (TrouSerS v0.3.1) and the above design comes from TrouSerS not from us. TrouSerS is currently being used on many Linux platforms that have TPM devices, all of which have the same configuration model. Deviating from the implementation in the ways you are proposing may be possible, but I would prefer to take that on as an RFE for later and work with the community to implement it in the original project code and not have to apply unique feature patches in our version. Presumably, this would involve adding new configurations that would allow for access to the TCS from a zone on the same system, but not from an external host. Our first priority is to get TrouSerS into Solaris. Improving it and making it take advantage of more of the unique Solaris features is more of a long term goal that I would be happy to work on once we have the first phase in place. > > to me it seems to me that each zone should have it's own copy of TSS > daemon with it's own tcsd.conf configuration file. It should be the > responsibility of the TPM device driver to manage requests from multiple > zones, with any zone device specific configuration being managed via > zonecfg. (that said, i don't have a complete understanding of the > TPM/TSS device interfaces, so there may be other better ways to > virtualize this subsystem to work with zones, and hence i'd be more than > willing to discuss options to improve the zones integration of this > feature.) Allowing for multiple TCS daemons in multiple zones would violate the spec and would not be acceptable to the upstream development community for TrouSerS. The TSS specification specifically states that the TPM should only handle accept connection at a time. The TSS daemon (tcsd) is also part of the specification and it is responsible for handling all direct access to the TPM. There are specifications for Virtualized TPM devices, but those are not yet implemented by our driver or the TSS libraries. I do believe working on the virtual TPM support is something we do plan to investigate in the future, though. -Wyllys
