On Tue, 2019-09-03 at 08:54 -0700, Lakshmi Ramasubramanian wrote: > On 8/30/19 11:41 AM, Mimi Zohar wrote: > > > No, the measurement list ima-sig template record contains both the > > file hash and signature. There's no need to maintain a white list of > > either the file hashes or signed hashes. All that is needed is the > > set of permitted public keys (eg. keys on the trusted IMA keyring). > > You are right - Thanks for the info. > > > Even though on the local system, files signed by the system owner > > would be permitted, the attestation server would be able to control > > access to whatever service. For example, Trusted Network Connect > > (TNC) could control network access. By measuring the keys on the > > builtin/secondary keyrings, that control is not based on who signed > > the software package, but based on who signed the certificate of the > > key that signed the software package. My concern is how this level of > > indirection could be abused. > Since the signer of certificate of the key that signed the software > package changes much less frequently compared to the certificate of the > key used to sign the software package, the operational overhead on the > server side is significantly reduced. > > I understand there is another level of indirection here. But I am also > not clear how this can be abused. The remote attestation server could gate any service based on the certificate signer. The first gated service, based on this feature, will probably be network access (eg. TNC). If/when this feature is upstreamed, every company, including financial institutes, organizations, and governments will become THE certificate signer for their organization, in order to limit access to their network and systems. Once that happens, how long will it be until the same feature will be abused and used to limit the individual's ability to pick and choose which applications may run on their systems.[1] Mimi [1] Refer to Richard Stallman's last paragraph https://www.gnu.org/phi losophy/can-you-trust.en.html > > All of this would still be true, if you measured the keys on the > > trusted IMA keyring, but without the level of indirection described > > above. Depending on your use case scenario, the problem with this > > approach is maintaining a list of all the certificates that have been > > signed by keys on the builtin, and if enabled, the secondary keyrings. > > Yes - that is the issue we are trying to avoid. Especially since the > list of signing certificates can grow faster than the signer of those > certificates (that are present in the builtin/secondary keyrings) > > > In the last LSS-NA BoF, Monty suggested, for a different use case, one > > that needs to seal keys, measuring keys and extending a separate PCR. > Thanks for the info. I will gather more information on this one. > > -lakshmi >
