On Mon, Sep 09, 2019 at 09:31:21AM -0400, Mimi Zohar wrote:
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,
I'm not sure why upstreaming this code will matter for those entities
you're concerned about. Any entity that provides a signed kernel image
is very well capable of including out of tree patches in that image.
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]
We do not restrict end use of the kernel; this is one of the main
reasons that the kernel is licensed under GPLv2 rather than GPLv3.
Please see https://lwn.net/Articles/200422/ .
We'd love to work with you on the technical aspects of this code to make
it acceptable to the IMA maintainers, but this work can't just be NACKed
based on a perceived end use of it.
--
Thanks,
Sasha
